[Dev] recent parabola changes to 'pacman'

bill-auger bill-auger at peers.community
Mon Apr 25 10:56:03 GMT 2022


On Sun, 24 Apr 2022 23:41:16 +0200 Denis wrote:
> Should we also build all these keyring packages? 

only the arch32 keyring has ever been a problem - i have been
rebuilding it whenever someone reports the problem


> If you don't keep your system up to date enough the keyring becomes
> impossible to upgrade safely. You end up needing the new keyring
> package to install the new keyring package

that is true; but this happens too often - the problem is
usually noticed on the install ISOs - the alternative is to
rebuild all 32bit ISOs, every time the arch32 keyring changes -
thats much more work than rebuilding the keyring; and totally
unnecessary otherwise


> Users wanting to upgrade from an architecture to another one will then
> have to do the switch manually. 

i must agree - when i first setup my arch32 VM, the first time i
ran pacman -Syu, it upgraded most of the entire system - i
keep it for testing bugs in parabola i686, before reporting
them upstream - so, i had to revert it to i686 and pacman -Syuu
- i do not like auto-magic either - i agree that changing
arches should be a conscious decision

the only good reason to keep auto, is because thats what the
arch pacman.conf has - i am comfortable with deviating from that
- your hard-coded implementation is better - the auto-detect
install hook approach would actually introduce a bug - install
hooks should not modify owned files - those files are hashed at
build time - when a package is upgraded, it checks files
installed under /etc ( or may only those in the backup=() array,
im not sure) to determine if they have been modified - if it
is not modified but that file is going to change, it installs
the new one as *.pacnew - if the file is modifed by an install
hook, it will never match the hash


More information about the Dev mailing list