[pacman-dev] [PATCH v4] libalpm: Add support for trigger dropins

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200823/4b89f67b/attachment.sig>