Can anyone explain why HaikuDepot waits until all the package dependencies are downloaded to then complain that a package is already installed and then halts the install? For example, tried to install aqemu. The prompt appears that other packages are necessary, fine. Click ‘apply changes’. Downloads commence. Then, after everything is downloaded, you might get a message like this: 
Shouldn’t the package management already know that this package is installed and use it or update it or remove it?
This error indicates that the file is already in your packages folder, but it is not activated. There are some issues/edge cases where files end up in the folder without them properly being accounted for. Best way to solve it is to manually remove the package file from /boot/system/packages and use HaikuDepot to reinstall.
How do files end up not accounted for? Could it happen from a failed download? Is there a command to scan for packages that are broken or not accounted for? Does the package system need to be more proactive or fault tolerant?
The only cause I have seen is when users try to upgrade the system from an installation medium, which the Installer pretends may work, but in reality is broken. This will be fixed by Beta 3.
It should not, when doing downloads the package system uses transaction folders.
Not that I am aware of.
I think the focus is best on why unactivated packages end up in the folder in the first place. I would focus on fixing those root cause issues before adding any workarounds or tolerances.
You can list packages in /boot/system/packages folder and compare to the list in the activated packages file.
Haiku allows you drop to drop packages in /boot/system/packages to install them.
What happen is that HaikuDepot try to solve dependencies for the dropped package and then pop something up asking to cancel if there’s a conflict or to download dependencies if any and install the package (in fact, activate it).
And it will do that for each package dropped.
So better avoid to drop several packages in same time otherwise you end up with several HaikuDepot pop-ups asking to download the same thing.
So, if you have no access to internet and really need to do it, you will have to manage dependencies ahead and split packages in groups i.e you will drop libs before executables or other libs depending on them.
I don’t know about all this…I’ve looked into the /boot/system/packages directory, found 562 entries. Looked into the /boot/system/packages/administrative directory, found a file called ‘activated-packages’ with 523 entries. I haven’t tried to upgrade the system from any medium. I have had many download stalls which result in fails. So what I’m hearing is that I have to occasionally compare the two for errors, or attempt to install a program, pause while I check the packages directory for entries that are already there and delete them so that the install will complete.
Both should be in sync.
I don’t know how so many ended up non-activated. As nielx said, it shouldn’t happen from an interrupted download.
When you install a package and so also when you run SoftwareUpdater, HaikuDepot makes a transaction-* folder in administrative subdirectory. Only once every package successfully downloaded, HaikuDepot proceeds to the real installation. So normally there shouldn’t be half-downloaded packages in the packages directory. But in administrative subdirectory, there’s probably a few transaction-* folders with one or several packages, last of these packages being not complete and so broken.
To solve your issue, I would find all packages that are not activated comparing lists, move these elsewhere in a new folder. Then, I would clean old transactions folders as they may take a lot of place. At this point, things are back in a clean state and there shouldn’t be errors anymore.
After that, I would examine the packages I removed to see what I need and what I don’t. I would reinstall those I really want through HaikuDepot (Since these packages were in packages directory, they are probably complete and not broken so you could also click on them or drop them back but our goal is to get out of trouble…) then I would delete the folder.
Ok, then is there a log I can follow or a way to have verbose output during package management? I guess I’m looking for a transactional trail I can examine to find out what is happening.
When a package is installed and activated, it is mentioned in syslog file (/var/log/syslog), you may find it sufficient to check that.
Otherwise, you can use directly pkgman in a terminal. The options are install, remove, update and full-sync. update and full-sync can both be used to update your system, the difference is that full-sync will allow downgrading a package. (This is sometimes needed when projects are changing the way they’re naming versions or if a new version of a package is accidentally pushed. So, usually 3 times a year max)
Also from a terminal, there’s a way to activate debug mode in HaikuDepot but I never tried.
See here for more details https://www.haiku-os.org/docs/userguide/en/applications/haikudepot.html
Thanks for this info. I’ll see what I can discover and report back.
Mazbrili’s question to Pulko Mandy:
“does filwip help in this situation?”
I can answer with an unequivocal YES!
FilWip is very handy but it is not selective. It will wipe all previous states leaving you with no fall back.
You don’t have to keep them all. Usually keeping last three or five previous states is sufficient. So, if you need some space in your Haiku partition, you can delete a few without problems. But, states are steps to go back in time and you can’t make a cherry pick of what you want to keep. You have to keep them contiguous. For example, let’s say today is Wednesday. To go back to Friday, Haiku will go back to Tuesday then from there to Monday, from there will go to Friday. It won’t do Sunday or Saturday because it’s the week-end, you didn’t use Haiku and so no updates and no state.
Unfortunately, FilWip and tools like it tend to mask problems. Better look for the cause of the problem like Scott intend to. Once known, it can help to solve it permanently.
Although FilWip has an option to exclude files, last time I checked it wasn’t really helping.
It won’t help you to clean up non-activated packages that ended up already in packages directory either.
I envision a service or an extension of package management that deals with this. As it is now, nothing is preventing a program (like FilWip) or a user from deleting states saved under the package structure however they want. This can, as you have stated, render falling back to a previous state potentially useless. As it is now, these states will build up indefinitely unless managed. Something akin to a kernel manager but for states (keep last ‘n’ amount). Perhaps another tool to sniff out mismatches between packages and those listed in activated-packages. Just thinking out loud, I really enjoy using Haiku and want it to be the best it can be.
Though, it will take time before Haiku has multi-user support, that’s the kind of thing a superuser password would probably secure enough.
Devs are already thinking about limiting the number of states for R1 but it isn’t easy. There are a lot of cases to consider. I.e when you install a package that has no previous version the state folder only contains an activated-packages file. Not so useful. Repeated few times, it defeats keeping last 3 strategy.
I think that problems like yours are more frequent since SoftwareUpdater was changed to use full-sync option instead of update. It can be that we didn’t noticed them because the tree was hiding the forest. But, there’s certainly something to do also there.
For what it’s worth, I usually use the terminal for updating with pkgman full-sync. I use HaikuDepot for installing new software. I think the FilWip type of app is the most appropriate way to clean the system as long as there is fine grain control of which states to clean. It is an interesting mental exercise to think about how to best manage package management. The rollback feature is great and needs to be leveraged to its maximum potential. Perhaps the user could flag stable prior states or the system could flag crashiness of states. I’m an automotive tech, we use things like misfire counters, fault codes, all indicators of performance issues. I’m thinking that a diagnostic counter of sorts could flag states that have regressions or the opposite could exist, a counter of succesful operation could elevate a state as worth keeping. Well, enough rambling.