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.
You actually can since they don't put it in the same place. You're also technically not forced to have dracut generate an initramfs. You could have it installed to play around with unified kernel images while mkinitcpio is installed to get the usual kernels/initramfs split images. And if you do have both installed and they both use kernel-install (let's not focus too much here on whether kernel-install is a good idea for Arch or not, that's a discussion for the Arch mailing list), it makes sense to me that they both reuse the same hook instead of having to almost exactly the same hook between the two packages, just with an extra Target line to include their own module directory.
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.
On systems without kernels the kernel-install hook would be a noop. One small annoyance is that it would still pop up in pacman's output even though it's not doing anything but that's something minor imo.
Can I hear an argument for where this functionality is generically useful, and in a case which isn't simply incorrect packaging?
If hook based packages switch to non-shell glob based patterns and instead have packages that install hooks also install their own trigger, a user can selectively disable some of these triggers. e.g. a user has a package installed that comes with a dracut hook but isn't interested in the hook and symlinks it to /dev/null in /etc so it doesn't run. However, when the package is updated, the pacman dracut hook will still trigger because of the updated dracut hook installed by the package. If the pacman dracut hook required external hooks to install their own triggers, the user could disable the hook in dracut and disable the trigger in pacman, resulting in the hook never being executed and also not triggering extra dracut runs by the dracut pacman hook. Adding more triggers is mostly useful for hook based packages depending on other hook based packages (kernel-install and mkinitcpio/dracut is a single example of this) where the nested hook based package can add its own hook directory as a trigger to the main package pacman hook. Assuming a package stores some stuff in a non-standard path and needs another package to run on that non-standard place when it's updated, it can add a drop-in to add that path to the list of triggers for that package's pacman hook. I realize that these are mostly niceties and I'm not solving some big massive issue packaging issue by adding this. Still, since there's not that much added complexity in the implementation and the user facing part (imo) so adding this seems worth it to me to make some of the mentioned use cases a little easier to handle. Daan On Sun, 23 Aug 2020 at 07:35, Eli Schwartz <eschwartz@archlinux.org> wrote:
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