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

[Daan De Meyer]

> 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 at 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
>