On 8/22/20 9:12 AM, Daan De Meyer wrote:
In some scenarios, instead of adding their own hooks, packages want to augment hooks already installed by other packages with extra triggers. Currently, this requires modifying the existing hook file which is error prone and hard to manage for package managers.
A concrete example where packages would want to extend an existing hook is using systemd's kernel-install script on Arch Linux. An example pacman hook for kernel-install could be the following:
``` [Trigger] Operation = Install Operation = Upgrade Type = Path Target = usr/lib/modules/*/vmlinuz Target = usr/lib/kernel/install.d/*
[Trigger] Operation = Install Operation = Upgrade Type = Package Target = systemd
[Action] Description = Adding kernel and initramfs images to /boot... When = PostTransaction Exec = /etc/pacman.d/scripts/mkosi-kernel-add NeedsTargets ```
This hook would run on installation and upgrades of kernel packages and every package that installs kernel-install scripts (which includes dracut and mkinitcpio). It's also fairly generic in that it doesn't include specifics of other packages except its source package (and implicitly the install directory of kernel packages).
However, both mkinitcpio and dracut use the concept of hooks that can be installed by other packages to extend their functionality. In mkinitcpio these are stored in /usr/lib/initcpio. When a package is installed that installs extra hooks for mkinitcpio, the kernel-install hook will not trigger. We can fix this by adding /usr/lib/initcpio/* to the kernel-install pacman hook but this requires either modifying the kernel-install hook when installing mkinitpcio or adding all possible directories for all possible packages that want to add triggers to the kernel-install hook in the systemd package itself. Neither of these are attractive solutions. The first one isn't because we'd have to modify the hook when installing packages, the second isn't because it would be a huge maintenance burden and doesn't include for AUR or private repository packages.
This all seems fairly specific to the kernel itself. As a matter of curiosity... why can't a mkinitcpio hook declare it is triggered on /usr/lib/initcpio and a dracut hook declare it is triggered on /usr/lib/dracut/modules.d/ ? In fact, the current mkinitcpio hook does precisely this, and is provided by the mkinitcpio package. It's all statically coded ahead of time, AFAICT the only reason to do it this way is to incorrectly put a kernel-install hook into the systemd package and make the mkinitcpio/dracut packages dynamically load themselves into said hook. There is currently no kernel-install pacman hook, and even if one did want to declare kernel-install the official way to manage kernels on Arch Linux, the systemd package is the wrong place to put it as systemd is installed on many Arch systems that don't have a kernel and should not run kernel-install hooks. If two packages provide mutually exclusive services, I think it's reasonable for them to also provide mutually exclusive pacman hooks geared to that package specifically. It's not like you can even use kernel-install with both dracut and mkinitcpio installed, since they both try to create the same initramfs. More likely, since kernel-install is only catering to a fairly narrow use case while being installed as part of the base system due to it being bundled as part of systemd itself, it will be the responsibility of people who actually like it to manually (no package) install their own hook to /etc/pacman.d statically coding the desired directory to watch, which will never ever ever change after the initial installation process. It's entirely reasonable for people to create their own custom hooks for their own system, augmenting the packaged hooks which are only supposed to be used for cases where it's unambiguously correct to run those routines. That is why there is a hookdir in /etc. I have a bunch of hooks which are totally unfit for general packaging but I wouldn't wish to live without. Can I hear an argument for where this functionality is generically useful, and in a case which isn't simply incorrect packaging? -- Eli Schwartz Bug Wrangler and Trusted User