Re: [RFC] dracut vs mkinitcpio vs booster

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872161655

Comment:
Part of this discussion gets charged because we start thinking about where we'd go when dracut becomes completely hostile to anything but systemd. Every release seems to take us closer to that point.

I now think the best thing we can do is try to decouple packages from a single initramfs generator. 876b6ed3a4da006639908794bff4eeaeb0f123eb is a start, replacing dracut-specific post-install scripts with a common XBPS trigger that is currently aware of mkinitcpio and dracut. Somebody can add booster, initramfs-tools, whatever to that trigger as needed.

The only other issue that remains is how to cleanly handle multiple installed generators. On some systems, I've been using mkinitcpio to ensure there is a clean transitional path. However, ZFSBootMenu still requires dracut. Having both installed means multiple kernel hooks compete (mkinitcpio would win here) unless I `noextract` the hooks I don't want. This works fine for people who know to do it, but we really need a method for multiple kernel hooks to coexist without all of them firing. I see two possibilities:
1. Every kernel hook is aware of `/etc/default/initramfs-regenerate` used by the XBPS trigger and will turn itself into a no-op if the configured generator does not agree with the one in the hook, or
2. We centralize the kernel hook, knowing how to create an initramfs for each generator and choosing the right one based on the configuration.
The first option provably violates DRY, but the second doesn't scale well beyond a handful of generators. No problem; we should never really have more than a handful available anyway.  I think (2) is a bit cleaner.

With the hook issue resolved, we can probably just define a virtual provided by all the generators. People can then just use what they want with no problems. The last issue is choosing a default provider, but that should obviously be dracut for a long time because we have a lot of inertia.