Pgkman: failed to commit transaction

Help
1

Hey all,

I’ve been playing around with Haiku for the last couple of days and have stumbled across a strange issue that has me stumped…

When I try to install gcc (from the terminal or HaikuDepot), pkgman downloads all the dependencies, but exits on the following error message when installing the binutils package:

*** failed to commit transaction: The to be activated package "binutils-2.31.1-2-x68_64.hpkg" does already exist.

I’ve tried running pkgman full-sync to no avail. I’m currently running R1/beta2.

Any help would be appreciated, or even just pointers or next steps I could follow to debug the problem myself!

Thanks for reading.

EDIT: Formatting.

2

Read here:

1 Like
3

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.

1 Like
4

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.

1 Like
5

Thank you very much everyone for your answers!

Unfortunately @un_spacyar , simply using FilWip did not solve the issue. I tried the method @Starcrasher suggested, and this worked perfectly.

Thanks again.

1 Like
6

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.

1 Like
7

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.

1 Like
8

Please open a bug report as well.

1 Like
9

@bitigchi Great suggestion! I was wondering if its still worth submitting a bug report if I am unable to reproduce the issue? I tried spinning up a new installation and it worked fine this time…

10

I’d say this is an error that should not be presented to the user. pkgman should clean or evaluate the transaction folder and solve it in itself. So, yes, I’d say this is worth a bug report.

1 Like
11

Submitted: #16573

1 Like
12

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.

13

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.

14

IIRC it is a side effect of this fix hrev51233 in package_daemon.

15

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…

16

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.