Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan <nowa@gentoo.org>]

On 15/03/2025 04:56, Ionen Wolkens wrote:
>>> This just feels like a messy half-solution that we're better off
>>> without.
>>>
>>> So NACK from me, both for linux-mod-r1 and adding support to my
>>> packages like nvidia-drivers.
>>>
>>> Not that I'll revert if it gets merged anyway.
>>
>> Is there anything I can say or do to convince you otherwise? I honestly
>> believe that I have addressed all concerns that have been raised so far.
> 
> I don't think so, it's more the idea in itself that I dislike than the
> implementation. Not that the latter helps with its kind of unintended
> hacked-on-top linux-mod-r1 implementation that (as you know) not all
> ebuilds can use right now... but I generally want to avoid requesting
> improvements given it's unlikely it'd change how I feel about this.
> 
> As noted on PR, *if* we really want to support rebuilding for multiple
> kernels it's something that could be done with a linux-mod-r2 eclass
> rather than dkms (not that it wouldn't require work because of the way
> current linux-info works, and some ebuilds would need to be adapted in
> a multilib kinda way), and I'm not convinced the "rebuild at boot" is
> really meaningful esp. with distribution kernels that are controlled
> by the PM.

I really don't see how we can reasonably solve this problem via eclass 
given that the number of possible kernel targets is way bigger then for 
example multilib, PYTHON_TARGETS etc. Plus we also have to account for 
kernels that are not built and installed by the package manager. In my 
opinion what you propose here is unnecessarily complex and I really 
doubt it will work.

> PM limitations could be improved in future EAPIs, like a way to have
> proper hooks for modules and initramfs rebuilding so that we wouldn't
> have to rely on (not really slot-able) virtual/dist-kernel and
> duplicated initramfs generation. It could potentially also clean old
> modules safely then. Such hooks system would also be handy for other
> things like rebuilding gtk icon cache and such rather than doing it
> per-ebuild (we may already have a bug for this somewhere?).
> 
> And I don't feel that this is all important/urgent enough that we need
> to establish (hacky) dkms usage in the interim as a "better than
> nothing" solution. *Vast* majority of users only care about one kernel,
> at most the old just need to be able to boot into a console to fix
> issues if something went wrong (that nvidia-drivers may mismatch with
> userspace is not great, but not getting GPU acceleration is not the
> the end of the world in that situation).
> 
> Not great but, if one rare user really needs to rebuild for multiple
> kernels, there are still (unintuitive) ways to do that in the interim
> such as emerging modules multiple times by pointing to different
> linux sources -- but again emphasis on that not really many need this.

Well I don't know what to say other then that I strongly disagree. This 
is not hacky, DKMS is the standard solution in many many other 
distributions and it works pretty well there. I really don't understand 
why it could not work equally well for us. In fact, I'll turn this 
around and say that our current solution with the slotted 
virtual/dist-kernel is hacky. It works poorly mainly because there is no 
relation between the actual kernel target and the installed slot of the 
virtual (other then a warning if the eclass detects a mismatch). This 
makes the binpkg situation here a mess. Downgrading is difficult. 
Portage is extremely slow in resolving all these slot dependencies. And 
all of this is not intuitive and very confusing for new users.

I do not agree that these problems are not important. Out of tree kernel 
modules are essential to many systems, and therefore this should "just 
work". Sure it's a fixable problem when it breaks, but it's annoying and 
requires manual intervention. Gentoo deserves better, and we can very 
easily make it better by doing what loads of other distributions are 
also doing (i.e. use DKMS).

I am **not** proposing this as an interim solution (I hate interim 
solutions), I am proposing this as a permanent alternative method of 
managing kernel modules where the package manager is less involved 
(while still retaining user compiler/flag preferences etc). Reworking 
linux-info so it can support multiple targets is still possible, these 
things are not mutually exclusive (though I still believe DKMS is the 
better solution even if we do rework the eclasses).

I really do not understand why you are so strongly opposed to this and 
use as your only arguments that a) the problem being solved is not 
important and b) the problem could be solved by some complex and vague 
other solution that does not currently exist.


I had really hoped to receive more comments on my earlier RFC. Because 
now I still feel like it's just you and me disagreeing and we are 
getting nowhere. I really do want to know what others think so I can 
make a better judgment on whether or not my idea is really this crazy 
and if I should just shut up about it or not (so dear reader if you have 
an opinion then please share).

Best regards,
Nowa