Apparently, that issue is caused because the package already exists in the temporal folder used by HaikuDepot.
An easy fix is install the FilWip application (available at HaikuDepot) an use it to clean the HaikuDepot temporal folder. Notice that this also will delete the previous packages states, just in case that you use it. Normally is not needed to keep it.
Look in /boot/system/packages, there’s already a package binutils-2.31.1-2-x68_64.hpkg there.
For some reasons (don’t ask me why) that package has never been activated. Move it somewhere else (Desktop to start then Trash when problem solved) and retry.
Note that since it is a system directory, you will have to hold shift key to perform the move.
After that, you may want to clean transactions directories in /boot/system/packages/administrative. They are directories containing packages from all attempts that failed.
The bigger question is why is it happening. It is a major pain especially on large downloads where you wait until the end to get this message that is non recoverable. Sure, we can go and remove the offending file, but there may be others. Sometimes on large downloads, I’ll go through a file search to compare what is going to download to what is potentially already on the computer and delete any files ahead of time. Very strange.
Although I’m relatively new to Haiku, I may have some hint to your question. I can say that the binutils package was found in the Haiku installer under the options to install additional software on installation. I had selected yes for that package. So the issue may lie there? Not sure, but just a tip.
We are seeing this problem more frequently lately.
The question is did the switch to --full-sync really improved the situation compared to what --update was doing?
Is it because that particular problem didn’t exist with --update or was it present but hidden by other problems?
This can also occur when people are dropping manually multiple packages in packages folder at once.
We probably thought that it was the case when it was reported at that time.
This is unrelated to full-sync vs update. The only difference between the two is that “full-sync” is allowed to downgrade or uninstall packages, whereas “update” isn’t. Other than that, the exact same code is used.
There are two problems interferring with each other here:
First, pkgman is unable to handle the case where a package is replaced with another one of the exact same name and version. This is a regression, it used to work. There is a ticket about it but I can’t find it right now.
Second, the support of optional packages, I think combined with the new code to activate packages on first boot, is apparently resulting in some packages being in the directory, but not activated, and the package daemon doesn’t pick them up when booting the new install. Normally this would fix itself as soon as you run pkgman or do some other package related operation (which triggers a rescan of the packages directory), but because of the first bug, it doesn’t work.
The second thing could maybe be fixed by forcing a rescan of the directory during the first boot of a newly installed system. But first we should fix the first one.
How is used activated_packages file? I thought that it was used to speed up boot process. Is it only a log?
From my understanding, if there’s a file, packages listed here are loaded, if there’s no file daemon consider all packages in directory as activated and to be loaded, right?
In that case, deleting the file should work to solve a problem on user side but sweeping administrative folder doesn’t seem to work…
It remembers which packages are already activated. So, yes, this can speed up the boot process, but also remember that the activation scripts for packages were already run, for example. So, just deleting it can result in accidentally re-running the install scripts. Probably not too much of a problem since we don’t use the feature a lot, but you never know.
Also there is a list of system packages that are initially activated no matter what and I think it can create some confusion as well. It seems a bit more complex than it looks on the surface, with transactions and states backup and everything taken into account.