Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

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
Task Type General Gripe
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 5.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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
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.
Comment by Doug Newgard (Scimmia) - Wednesday, 20 December 2017, 06:43 GMT
They are prioritized, filesystem is just more system-critical than gcc-libs. I have no idea how the hell the filesystem upgrade errored out.
Comment by Eli Schwartz (eschwartz) - Wednesday, 20 December 2017, 07:01 GMT
packages which are dependencies of other packages are supposed to get bumped up the queue already, but there is nothing about the filesystem package that requires gcc-libs to be installed.

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...
Comment by Dave Reisner (falconindy) - Wednesday, 20 December 2017, 08:43 GMT
Dupe of FS#23011?
Comment by Max Thomas (shinyquagsire23) - Wednesday, 20 December 2017, 09:34 GMT
Ah, probably a dupe of FS#23011, sounds about the same. I'll go ahead and close this then.

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.
Comment by Andrew Gregory (andrewgregory) - Sunday, 24 December 2017, 18:29 GMT
FS#23011 should effectively be solved following ec831e05f58e3db1c06aadb23a87b5b82ab3ebf3. Implementing delayed removal of replaced packages may have preventing breaking pacman in your particular case, but the real problem here is that the transaction was aborted after being started. Pacman checks for file conflicts prior to starting the transaction, so we need to determine why pacman didn't detect the conflict. The only reasons pacman should miss a file conflict are if you managed to create the conflicting file between pacman checking for conflicts and starting the extraction or if you replaced an existing package-owned directory with a file or vice-versa. Is that what happened?