17.03.2025 10:11, Nowa Ammerlaan пишет: > 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 > > > Well, I don't know whether my opinion counts for much, but count me in to add USE="dkms" to my make.conf the moment this is merged. I do use more than 1 kernel and the current situation with @module-rebuild often makes me boot to a kernel without all the required modules, so I end up without my home directory after a reboot because portage randomly decided to not rebuild zfs module for certain reasons.
I haven't looked at the implementation in the PR, so can only comment that DKMS on Ubuntu worked very well, back before I switched to Gentoo, specifically because of how DKMS handled nvidia drivers.
