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

[Eli Schwartz]

On 8/23/20 6:32 AM, Daan De Meyer wrote:
>> 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.

One initcpio is generated by
/usr/lib/kernel/install.d/50-mkinitcpio.install and one by
/usr/lib/kernel/install.d/50-dracut.install, if both are installed then
they both write a kernel to BOOT/MACHINE-ID/KERNEL-VERSION/initrd

I don't understand the purpose of having these both autogenerate the
same file. Actually I don't understand the potential purpose of having
them both autogenerate different files at the same time either...

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

Why does it matter how similar the hooks are, these are very small files...

That's just not a good argument IMO. That's an argument for adding
additional features to pacman, with the intended use of allowing a
single package to do the same thing twice, after throwing out the
efforts of the first time!

This isn't about whether kernel-install is a good thing (people use it,
their reason for using it is because they like it, therefore for them
it's presumably a good thing...). It's about whether kernel-install
using *both* dracut *and* mkinitcpio at the same time is a good thing.
I'm confident it isn't.

I'm more than happy for user choice, so if people like hooks for
kernel-install they're more than welcome to use it. But there is *zero*
reason for competing implementations of the same thing to do the same
work twice, and we should not be adding additional features to pacman
for that sole use case.

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

If you want to add no-op hooks on your own system, that's fine, but I
believe it's quite rare to do so in the official repos at the moment...
because generally they are installed in the same package that uses them.
I'm not sure I see a compelling argument to install things in the wrong
package just because they won't get used unless you install the right
package.

It's not a small annoyance which is worth it due to $benefit.

It's a small annoyance with absolutely no reason to exist, and no
benefits, and the sheer lack of a point would make me, as a user, more
annoyed than I would be otherwise.

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

I'm pretty sure we don't want to force every single package providing a
dracut/modules.d/ file to also install additional pacman hook files
instead of using globs for their intended purpose, as this would then
mess up the expected functionality of those other packages, and in all 3
cases for dracut, they're installed by the upstream build system, not
the Arch packager -- so this would force the packagers to maintain an
absolute filelist by hand.

Maybe it would be interesting to look into having NoExtract'ed files not
trigger hooks, instead. Users could prevent installation of dracut files
they don't want to use, and as a bonus, if you suddenly decide to use it
you track this by starting to install the file, rather than just
building the initrd and then forgetting the hook doesn't watch for
rebuilds anymore and having it not rebuild when it should.

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

You don't need to re-explain to me "what" it does, this is evident in
the initial patch submission. :)

But again -- I don't see how this is useful for anything other than one
arguably wrongly-implemented kernel package (which is not actually
implemented yet).

My argument is you "shouldn't" do this.

...

I'm also not sure what "nested" hooks have to do with this, since pacman
hooks aren't nested and kernel-install would only be one hook that
(re)builds an initramfs as part of its internal functionality.

Do you want to be able to have a hook that is also triggered when
another named hook is run? That's a different proposal, but color me
intrigued.

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

I'm definitely up for improving niceties, there's no problem there. :)

My only concern here is that I don't think this is a nicety -- I think
it's an incorrect approach.

-- 
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/4f4fcb52/attachment.sig>