On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote: > Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted: > > > I had really hoped to receive more comments on my earlier RFC. [...] > > 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). > > So because I carried over my own already "works for me" kernel maintenance > scripts from Mandrake when I switched in 2004 and have continued > maintaining and using them over the decades since, I normally try to stay > out of Gentoo kernel packaging discussion. But given both the above > explicit invitation and that as I've read the thread a thought occurred to > me... > > First, DKMS /is/ a cross-distro standard solution. As such, I believe in > general it should be reasonably supported in Gentoo unless it simply > doesn't make sense (note that "doesn't make sense" can also include the > case of simply no one stepping up to do it, not the case here). > > But, the thought that occurred to me reading the thread, was that there > are obvious parallels between this and another very significant and > controversial now "cross distro standard solution" (which I guess I don't > need to name explicitly). > > As there, I believe "the Gentoo approach" should (again assuming developer > willingness to do the work, seemingly the case here) make it available as > an additional integrated *option*, while keeping the current Gentoo option > as well. > > So I support DKMS integration /as/ /an/ /option/.
If anything, if go forward with this, I'd rather that it be with the plan to (eventually) either make it the default after enough testing and then later drop support for the old way entirely (then merge the eclasses), or revert if we think it's no good. One of the thing I did not like here is the idea to gain more ways to do the same thing that need to be tested to ensure some quality. Can't ignore it and leave it all to Nowa given if e.g. nvidia changes some path or something else and I don't test it on bump, then I push a broken package for all dkms users until someone reports it. Would even need to boot with it to be sure. It's nice to have choices in general, but still need to draw some lines to keep things maintainable. And if picking, in the end do we pick an option that requires to install sources and (imo) adds very little, or let the PM (that has access to sources unlike binary distros) handle it (with full control for handling issues) just like for dist kernels and improve on that as needed? Either way, as I said initially, I won't revert if this gets merged (even if optional forever). Just stating that I don't like it and probably won't offer real support, not blocking it. wrt merging eclasses, could add that I wasn't really against the support for this being in linux-mod-r1 directly except for the part where it did not work when not using modlist being confusing, in the end I'd probably just have asked for Nowa to add themselves as maintainer. On a related note about modlist, I've been semi-regretting keeping that modlist-type idea from the original linux-mod eclass and felt that a simple emake wrapper (incl. modules args) for all packages "might" have been better and easier to use for ebuilds and not miss modules on bump and had been pondering "potential" deprecation in the future (not that I had really explored that idea yet, would need to check packages). -- ionen
signature.asc
Description: PGP signature
