FS#23011 - Don't remove replaces earlier than necessary

Attached to Project: Pacman
Opened by Dan McGee (toofishes) - Tuesday, 22 February 2011, 22:12 GMT
Task Type Bug Report
Category Backend/Core
Status Assigned
Assigned To Dan McGee (toofishes)
Architecture All
Severity High
Priority Normal
Reported Version 3.4.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No

Details

As seen with util-linux-ng -> util-linux name transition.

http://mailman.archlinux.org/pipermail/arch-dev-public/2011-February/019504.html

We should really be treating util-linux-ng as the previous version counterpart to util-linux, just like we do on a normal upgrade (removing the local package first). This obviously gets a lot tricker when it isn't a 1-to-1 replacement, but we can still remove it as part of the first rather than at the start of the transaction.

We also don't handle dependency resolution order quite right in this case, as util-linux ends up last even though the dep chain looks like this:
kernel26 -> mkinitcpio -> util-linux-ng (replaced by util-linux)
This task depends upon

Comment by Allan McRae (Allan) - Thursday, 21 June 2012, 11:53 GMT
We hit this again with udev -> systemd-tools. If glibc was installed between the time udev was removed and systemd-tools, kernel panic ensued (dues to the "init u" call).
Comment by Andrew Gregory (andrewgregory) - Saturday, 18 May 2013, 20:13 GMT
The need for this is at least partially alleviated by taking indirect dependencies into account, as implemented in this patch on the ML https://mailman.archlinux.org/pipermail/pacman-dev/2013-May/017207.html
Comment by Damian Nowak (Nowaker) - Sunday, 07 September 2014, 17:06 GMT
Also ^C may be extremely dangerous if replacement isn't installed right after deleting the old package. https://bugs.archlinux.org/task/41854
Comment by Dave Reisner (falconindy) - Sunday, 07 September 2014, 17:18 GMT
> Also ^C may be extremely dangerous if replacement isn't installed right after deleting the old package.
This goes without saying. Interrupting *any* transaction during the install phase is dangerous.
Comment by Damian Nowak (Nowaker) - Sunday, 07 September 2014, 17:19 GMT
Sure it's dangerous, but when there are any replacements to install, it's getting to be extremely dangerous.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 06 September 2017, 09:31 GMT
I think I just ran into another case of this bug after splitting flatpak-builder from flatpak:

- flatpak 0.9.8-1 is installed.
- flatpak 0.9.10-2 and flatpak-builder 0.9.9-1 are available.
- flatpak-builder has replaces=('flatpak<0.9.10') and depends=(flatpak)

If the user confirms the replace, pacman will first remove flatpak and later upgrade it, throwing two errors:

error: could not remove database entry flatpak-0.9.8-1
error: could not remove entry 'flatpak' from cache

The upgrade seems to work fine except for the noise. Perhaps this would cause more problems if flatpak had more complex pre/post scripts, as this bug probably triggers unwanted runs of the install and remove functions.

Loading...