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
