Re: "depmod: WARNING" after kmod update

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

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

New comment by TeusLollo on void-packages repository

https://github.com/void-linux/void-packages/issues/38367#issuecomment-1213297831

Comment:
I'm going to leave the following as MY OWN PERSONAL OPINIONS and SUGGESTIONS:

1. It was always known that `dracut`was growing more and more systemd-centric. I recall Void Devs having a discussion on _github_ about it (Which I can't find anymore, it would be useful if someone could eventually link it). Eventually, it was anticipated something would break due to some systemd-based mishap. 

2. Given the current situation, this `dracut` update will require extensive testing, putting a lot of pressure on core devs. However, there's no guarantee a further `dracut` update down the line (Maybe even the next one) will not require another extenuating testing session, further undercutting core dev development time which could be spent anywhere else, assuming also that next version `dracut` won't be systemd-only at all, knowing also how much of a moving target systemd is. 

3. At this point, since `mkinitcpio` does not seem under-maintained anymore, and since the new `booster`, although not as minimalist as `mkinitcpio`, seems also to work reasonably well, I would say to just jump ship, and prepare to switch to a `mkinitcpio` configuration by default for Void Linux, with `booster`as supported yet experimental (It still has some maturing to do, it's very recent), and `dracut` as unsupported due to excessive systemd dependencies.  

4. To me, gradually dropping `dracut` in favor of alternatives will eventually become necessary anyway due to systemd woes, and this would be a reasonable occasion to jump ship. None will blame Void Devs, since it's known how `dracut` has grown to become increasingly unresponsive to non-systemd approaches. Also, even should eventually `mkinitcpio` be dropped by its original author/maintainer, it wouldn't be catastrophically difficult to perform some maintenance along with Alpine/Gentoo/Devuan devs, even if Arch too abandons `mkinitcpio`. Furthermore, the maturing `booster` would also provide a further safety net, if not as minimalist. 

I would say thus to minimize chances of potentially wasting time, efforts, and energy into something that tomorrow may very well grow into yet another systemd (Sarcasm MODE ON) "non-monolithic binary" (Sarcasm MODE OFF), and concentrate efforts into `mkinitcpio` and `booster`. In fact, it probably has not been this favorable switching to less conventional initramfs for Linux Distros in quite a few years, if not decades, thus I would say to just jump ship. 

In every case, I would like to thank both Void Devs and the entire Void Community for devoting their time and efforts into something excellent which has earned to only rely on the best. 

Now, it would be useful if one of the Core Devs could chime in, possibly. 
Thanks for reading, and remember: the aforementioned are just MY OWN PERSONAL OPINIONS and SUGGESTIONS.