FS#62826 - [pacman] [archlinux-keyring] dependency relationship is backwards, leading to populate failure
Attached to Project:
Arch Linux
Opened by Eli Schwartz (eschwartz) - Thursday, 06 June 2019, 07:08 GMT
Last edited by Jonas Witschel (diabonas) - Thursday, 28 July 2022, 16:28 GMT
Opened by Eli Schwartz (eschwartz) - Thursday, 06 June 2019, 07:08 GMT
Last edited by Jonas Witschel (diabonas) - Thursday, 28 July 2022, 16:28 GMT
|
Details
The pacman package has a dependency on archlinux-keyring,
but does not actually need it. pacman does, in its default
configuration, require signing, but that can of course be
configured away -- and additionally, any keyring will do as
long as it matches the mirrorlist sources. Thus, the keyring
should be a distribution policy (e.g. membership in the base
group) rather than a package dependency.
archlinux-keyring does not depend on pacman, but it should -- because its post-install script needs to run pacman-key. The current workaround is to check whether pacman-key exists and is executable before running the post-install, but the consequence of that is it is never executed at all. The outcome of this is that when pacstrapping a new installation, the OOTB pacman keys are just the ones from the host system, for example an install ISO. Depending on how old that ISO is, the keyring could be quite out of date. With the latest version of arch-install-scripts (see https://git.archlinux.org/arch-install-scripts.git/commit/?id=53debcefab227fc66ba85a9712b662145ff42d91 for details), pacstrap will ensure a working keyring exists in a newly installed Arch Linux rootfs, early enough that archlinux-keyring can make use of it to --lsign the master keys. This represented step 1 of getting the keyring to cleanly populate in a new Arch Linux installation. Step two proposal: remove depends+=('archlinux-keyring') from pacman add depends+=('pacman') groups+=('base' 'base-devel') to archlinux-keyring. ... This change should ensure that events like |
This task depends upon
Closed by Jonas Witschel (diabonas)
Thursday, 28 July 2022, 16:28 GMT
Reason for closing: Implemented
Additional comments about closing: archlinux-keyring 20220713-2, base 3-1, pacman 6.0.1-6
Thursday, 28 July 2022, 16:28 GMT
Reason for closing: Implemented
Additional comments about closing: archlinux-keyring 20220713-2, base 3-1, pacman 6.0.1-6
> The pacman package has a dependency on archlinux-keyring, but does not actually need it. pacman does, in its default configuration, require signing, but that can of course be configured away
...
Given the current base metapackage, archlinux-keyring should be added to the base *package*, removed from pacman, and made to depend on pacman. Installing base would require the keyring, and order it before pacman.
After some people spent a while trying to figure out what was wrong, I linked them this bug and told the user to reinstall the keyring, which fortunately always works for this because it just needed to repopulate the refreshed keydata, not edit keys in the install script, but... not really good UI here, honestly.
It would be nice to get this fixed...
pacman-key is being called in the install script, so declaring pacman as dependency of archlinux-keyring sounds like the right thing to do
furthermore pacman itself doesn't require archinux-keyring, but thats a property required to run "an Arch Linux", which is better reflected by adding it to the virtual base package.
So as far as I can see, we can two things for free: a more technical correct declaration/definition and a fix for this issue. This issue lays around for nearly two years now, if its a matter of workload I'm happily helping to get it sorted. Otherwise it would be nice to hear concerns if there are any.
Another simple solution would be to just use `gpg --homedir /etc/pacman.d/gnupg/` instead of pacman-key in the post_install script. gnupg gets installed before archlinux-keyring.
Edit: Ok, so --populate is more complex than I thought. This may not be a good option.
These packages are currently in [testing], please do as the name of that repo implies and try the changes in existing installations, new installations using pacstrap, build chroots, containers etc. ;)
IMHO the best way to fix this would be to recreate our build chroots regularly, but that's a topic for another (probably already existing) bug report ;)
On a long shot we should auto clean chroot packages and have an internal chroot version to autonuke whenever we need to introduce "breaking changes". But thats really more a followup for devtools :)