On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote: > 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.
(by the modlist bit, by that I meant initially -- I know dkms support been added to emake-type ebuilds too now) > 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
