Opened 19 months ago

Last modified 4 weeks ago

#15068 new bug

[packagefs] Cannot handle package activations with identical names

Reported by: waddlesplash Owned by: bonefish
Priority: high Milestone: R1/beta3
Component: File Systems/packagefs Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13574, #15207, #15576, #16573
Platform: All

Description

If you try to update or activate a package with an identical name (including revision) to an installed package, this occurs:

[system] Applying changes ...
*** failed to commit transaction: Failed to change the package activation in packagefs: Name in use

That's because of this code in packagefs.

Probably solving the TODO about looking packages up by node_ref rather than name would fix this.

Change History (22)

comment:1 by waddlesplash, 19 months ago

Blocking: 13574 added

comment:2 by waddlesplash, 16 months ago

Blocking: 15207 added

comment:3 by diver, 12 months ago

Blocking: 15576 added

comment:4 by diver, 7 months ago

Milestone: UnscheduledR1/beta2

Would be nice to fix before beta2 as it might prevent system updates.

comment:5 by pulkomandy, 7 months ago

System updates always come with a different version or revision number so they are not affected. Only trying to reinstall an already installed package will fail.

comment:6 by diver, 7 months ago

Still this is somehow happens: after a fresh install pkgman tries to update a selection of packages with the ones with the same name.

comment:7 by waddlesplash, 7 months ago

IIRC it was hard to get this problem to reproduce in the past; so are you saying this always reproduces under a beta2 image?

comment:8 by diver, 7 months ago

I haven't tried beta2 images yet but I could reproduce it easily using nightlies after a fresh install.

comment:9 by waddlesplash, 7 months ago

OK, then we should at least investigate why this occurs and fix that bug. It is indeed extremely odd.

comment:10 by Forza, 6 months ago

Hello,

This problem happens with the beta2 release-candidate too (haiku-r1beta2-hrev54154_107-x86_64-anyboot.zip) Currently, every time I make a clean install and run the sw updater.

https://paste.tnonline.net/files/vNna30rJuAt6_haiku-update-fails-on-clean-install.png

comment:11 by waddlesplash, 6 months ago

Can you please run "pkgman full-sync" in a Terminal, and paste the output of what it says it is going to do here?

comment:12 by waddlesplash, 6 months ago

Milestone: R1/beta2

Ticket retargeted after milestone closed

comment:13 by waddlesplash, 6 months ago

Milestone: R1/beta3

in reply to:  10 comment:14 by nielx, 4 months ago

Replying to Forza:

Hello,

This problem happens with the beta2 release-candidate too (haiku-r1beta2-hrev54154_107-x86_64-anyboot.zip) Currently, every time I make a clean install and run the sw updater.

https://paste.tnonline.net/files/vNna30rJuAt6_haiku-update-fails-on-clean-install.png

I think you were running into #16092 instead. Installer did not properly do a clean install and makes a mess of the package directory.

comment:15 by mmu_man, 4 months ago

Well this always happens when I full-sync after pushing a recipe to HaikuPorts with a package I built and install myself for testing. It tries to replace the one I built (with me as packager) with the one from HP, which has the exact same version. So it's quite easy to reproduce : build any package yourself and install it, then try to full-sync.

comment:16 by mmu_man, 4 months ago

Here it does this:

The following changes will be made:
  in system:
    upgrade package ocp_x86-0.2.2-1 to 0.2.2-1 from repository HaikuPorts
Continue? [yes/no] (yes) : 
100% ocp_x86-0.2.2-1-x86_gcc2.hpkg [4.53 Mio]
Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/master/x86_gcc2/current/packages/ocp_x86-0.2.2-1-x86_gcc2.hpkg...done.
[system] Applying changes ...
*** failed to commit transaction: Failed to change the package activation in packagefs: Name in use

comment:17 by mmu_man, 4 months ago

Admittedly it shouldn't happen with non-dev users who don't build their own packages.

comment:18 by pulkomandy, 4 months ago

I suspect this could be related to the problem in haikuports, where if you fix a requires or provide and rebuild a recipe, it will fail to activate in the chroot?

comment:19 by pulkomandy, 2 months ago

Priority: normalhigh

comment:20 by pulkomandy, 2 months ago

Bumping priority because this makes using haikuports annoying.

I guess packagefs is right to complain that another package with the same name is activated, but should notice that it is going to be replaced?

I guess one option is to make sure the "change activation" request sent to packagefs has the disabling of the old package first, and enabling of the new one only after that? Or it should be a "reactivate package" instead of an "activate package"? In which case the linked code for packagefs would be ok, and the problem would be in the package daemon instead. And indeed the daemon does activation first, then deactivation, and never uses the "reactivate package" code.

Last edited 2 months ago by pulkomandy (previous) (diff)

comment:21 by waddlesplash, 7 weeks ago

Blocking: 16573 added

comment:22 by kallisti5, 4 weeks ago

"the problem in haikuports"

aka endless loop of:

waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated

Just mentioning it here to make the error searchable :-)

Note: See TracTickets for help on using tickets.