On Fri, Mar 14, 2025 at 08:47:37PM +0100, Nowa Ammerlaan wrote: > On 14/03/2025 17:23, Ionen Wolkens wrote: > > On Fri, Mar 14, 2025 at 01:48:50PM +0100, Nowa Ammerlaan wrote: > >> eclass/linux-mod-r1.eclass | 7 +++---- > > > > ftr my opinion on this hasn't changed since the beginning, I was hoping > > that the idea would be scrapped early rather than more work being put > > into it. > > I noted your initial concerns and sam's hesitation, and would have > stopped pursuing this further had I not also received positive feedback > convincing me that there is indeed some demand for adding DKMS support > as an option. I had hoped that the final version of the new eclass, > being significantly cleaner and more robust, would have changed your mind. > > > 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. 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. > > Adding support for the DKMS pathway to only a subset of kernel modules > is bound to be lead to a confusing end result, so that is not really a > state in which I want to merge this in. > > Best regards, > Nowa > -- ionen
signature.asc
Description: PGP signature
