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