FS#56784 - System-critical superseded packages should be prioritized in the install queue
Attached to Project:
Pacman
Opened by Max Thomas (shinyquagsire23) - Wednesday, 20 December 2017, 06:23 GMT
Last edited by Allan McRae (Allan) - Wednesday, 14 March 2018, 05:57 GMT
Opened by Max Thomas (shinyquagsire23) - Wednesday, 20 December 2017, 06:23 GMT
Last edited by Allan McRae (Allan) - Wednesday, 14 March 2018, 05:57 GMT
|
Details
Description:
I recently performed a system update which included updates to gcc-multilib and gcc-libs-multilib (which had its package migrated into the main gcc and gcc-libs if I'm understanding correctly). Along with this, I had an upgrade to the filesystem package, which ended up erroring probably because of something I did, I frequently compile programs on my own and from AUR so my filesystem is littered with non-pacman files. Where things went wrong was when pacman had finished downloading all of its packages. It started by removing all of the superseded packages, and once all of the superseded packages were removed, the rest of the packages to be installed started installing. Since gcc and gcc-libs were not at the top of the queue, filesystem errored and pacman exited and dropped my system into a state where pacman could no longer launch because GCC libraries were missing. I understand this this could be labeled as a non-issue because in an ideal world there wouldn't be errors in package upgrades, but realistically? I use this machine for development, there will always be things breaking every so often and that's fine, but I think there's a serious argument for avoiding breakage of system-critical packages just because some package earlier in the install queue happens to fail. I suppose the real issue is that pacman aborted at the semblance of anything wrong, if it continued and let me know the package failed later then gcc-libs would have installed and pacman wouldn't have broke. Though just to throw this gripe in here, why isn't pacman just statically linked? At least then it wouldn't break all the time when some system upgrade goes awry. It honestly should be common sense that the *one program* which can make or break the system should always work, even if it means the executable might be a bit larger. Additional info: * The pacman.log snippet of the failed upgrade is attached Steps to reproduce: * Have a system-critical/pacman-required package be superseded by another package * Have a package alphabetically higher than the new package for the superseded package error during installation * The entire Arch install is broken, pacman doesn't launch (and most system apps don't either because stdc++), and the system needs to be repaired with a rescue ISO 
pacman-fails.log
(5.3 KiB)
|
This task depends upon
Closed by Allan McRae (Allan)
Wednesday, 14 March 2018, 05:57 GMT
Reason for closing: No response
Additional comments about closing: Probably user replacing directory with a symlink.
Wednesday, 14 March 2018, 05:57 GMT
Reason for closing: No response
Additional comments about closing: Probably user replacing directory with a symlink.
There are three aspects to every pacman transaction.
There are pacman hooks, which run before or after the *entire* transaction, and do not apply here.
There are the pre/post install/upgrade/remove scripts, which are run before or after each individual package, and don't cause pacman to fail, therefore they do not apply here. If necessary, the relevant commands can be run after pacman, anyway.
There are the actual package files themselves, which are extracted from a tarball via the libarchive functionality linked into the pacman binary, and cannot fail, at least not because of the dependent libraries disappearing in the middle, since pacman has them loaded into memory... and therefore do not apply here.
Whyever and however the filesystem package managed to error out, it does not seem to have anything to do with the install scripts anyway, and when it comes to merely extracting files to disk, there isn't much that can go wrong...
Apparently this bit was missing from the log, but the actual cause of the error was /usr/local/share/man/ existing while a symlink to /usr/local/share was added in the package. Some FPGA toolchain I had installed had man pages there already apparently. Always seems to be the symlink changes that kill my installs for some reason.