Arch Linux

That is a problem I have been thinking about for some time. However, SyncFirst is IMO the wrong place to do this, for me SyncFirst is a feature supposed to be used by the package management system. Of course, you may configure this on your systems however you wish.

A proper solution would be to make it possible to delay certain post_install tasks to the end of the install process, after all packages have been upgraded - however, no work has been done in that direction.

> pacman -Si kernel26
Repository : core
Name : kernel26
...
Depends On : coreutils linux-firmware module-init-tools
mkinitcpio>=0.5.20


mkinitcpio should always install first if both that and kernel26 are in the same transaction.


> pacman -S kernel26 mkinitcpio
warning: kernel26-2.6.34.1-1 is up to date -- reinstalling
warning: mkinitcpio-0.6.7-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...

Targets (2): mkinitcpio-0.6.7-1 kernel26-2.6.34.1-1

Total Download Size: 0.00 MB
Total Installed Size: 109.44 MB

Proceed with installation? [Y/n] n


So this appears to be working as it should...

It is more subtle than that. Packages used by mkinitcpio that are not depends of it might be updated afterwards. Example: You have 'mkinitcpio kernel26 lvm2' in your list, but the new lvm2 has a hook change that is required for lvm2 to work properly inside mkinitcpio.

In the past with klibc this was even worse ... I have actually not seen any of these problems since mkinitcpio 0.6, but I still like my proposal. On critical machines, I still run mkinitcpio manually after -Syu has finished, just to be safe.

harvie, have you actually had such a problem recently?

brain0: no, but i've experienced similar problem... mkinitcpio brought some new configuration files (*.pacnew) and immediately it started to update initrd as kernel26 have been updated in the same transaction, it was showing lot of errors during mkinitcpio execution... if it was in syncfirst, i will be able to fix configuration of mkinitcpio before rebuilding initrd. anyway. i have rebuilded initrd again when mkinitcpio was correctly configured to be sure that system will boot.

Can you remember what kind of errors exactly there were? I think they should be in pacman.conf.

brain0: and yes. there should be some directory for some after-transaction hooks. it shouldn't be hard to do... just something like classic *.d directories:

if test -d "$dir"; then
for script in "$dir"/*; do
test -x "$script" && "$script"
done
fi


imho there should be also some prototypes for frequently hooked operations... simplest eg.:

restart_service() {
/etc/rc.d/"$1" restart;
}

and some deduplication, so one service will not be restarted twice.
most hated feature is reloading icon database each time some desktop app is installed (several times during one transaction).
this can be done using three methods:
1.)
echo update-desktop-database >> hooks/dedup;
echo update-desktop-database >> hooks/dedup;
echo update-desktop-database >> hooks/dedup;
cat hooks/dedup | sort -u | bash
rm hooks/dedup

2.)
echo update-desktop-database > hooks/update-desktop-database
echo update-desktop-database > hooks/update-desktop-database
echo update-desktop-database > hooks/update-desktop-database
run-hooks
rm hooks/*

3.) using some hash array...

brain0: it was something with unproper *.pacnew files in *.d directories of mkinitcpio configuration and few minor errors than i cannot remember.
what means to add error into pacman.conf? there is some error message detection system? i have anything similar in my pacman.conf...

i think that better idea than adding error messages is adding mkinitcpio to syncfirst ;)
(if you are now familiar with solving this in pacman.conf)

Sorry, I meant to say the error should be in /var/log/pacman.log, not pacman.conf.

Ah... that is much more subtle.

The only way this can be fixed is when we implement hooks. It only has a rough design document so far... (http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks)

Even kernel26-headers should be syncfirst as some GPU modules are recompiled while running mkinitcpio.

No, they are not.

UPDATE: This actually happend few months ago to me. I've updated computer that wasn't updated for a long time and after reboot i ended in broken mkinitcpio. i had to boot from archlinux CD, chroot to the system and reinstall kernel package one more time (with new mkinitcpio). I wasn't able to fix it for two weeks because i had to burn the CD at home and bring it to my client (which have office far away from me). This is an issue!

> A Project Manager has denied the request pending for the following task:
>
>  FS#20165  - Add mkinitcpio to SyncFirst in pacman.conf
> User who did this - Allan McRae (Allan)
>
> Reason for denial:
> kernel26 depends on mkinitcpio so a new mkinitcpio is always installed before kernel26.

Well. so why initrd wasn't build properly at the first try (but second performed well)? maybe some of mkinitcpio hooks wasn't ready during the upgrade... how can we handle this?

Maybe mkinitcpio should not be in SyncFirst, but kernel26 should be in "SyncLast" (which is currently nonexistent feature :-)