Nowa Ammerlaan <n...@gentoo.org> writes: > On 19/03/2025 02:07, Ionen Wolkens wrote: >> 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. > > As I have already stated elsewhere, DKMS can do things that we cannot > achieve with the package manager, and the package manager can do > things that we cannot achieve with DKMS. Each pathway has its use > cases. And for that reason DKMS is not a replacement for the package > manager. Nor can I think of a possible future package manager based > solution that can fully replace what DKMS does (though who knows, > maybe someone will prove me wrong in 20 years) > > This dual-approach is not controversial either, other distributions > often offer a "normal" package as well as a DKMS package. Now since we > have USE flags we do not have to make two separate packages, but > nonetheless the core of letting the user choose to use DKMS or not > remains the same. > >>> 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. > > I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms, > especially if the ebuild does not use a modlist and therefore the > dkms.conf is not constructed fully automatically. Though I do not see > why this would require actually rebooting the system for both > cases. DKMS either builds and installs the module successfully in > postinst or it does not. And regardless of who did the module > installing, it either loads successfully or it does not. Note that we > are intentionally using the exact same commands to actually build the > module in DKMS.
If we're doing it orphaned, it should be done as hooks instead rather than with any integration in the ebuild, though. postinst / orphaned files are broadly a hack. Orphaned files break a bunch of invariants including Just Working for binpkgs properly. I also agree with Ionen that this is important enough that I'd want this to be the primary path (and fully tested & supported), not done at all. But wanting to support *both* long-time makes me uneasy. > [...] > >>> It's nice to have choices in general, but still need to draw some >>> lines to keep things maintainable. > > This maintainability argument would be a lot stronger if I was > reinventing the wheel and proposing some custom Gentoo specific > solution to the problem at hand. Note though that this is not what I > am doing (in fact one could even turn that around and say that this is > what you are doing). You are of course right that more options means > more things to test. But really, it's not a lot of work, I know > because I did the work for almost all of the kernel module ebuilds we > have in ::gentoo and was finished in half a day. The bulk of the work > was designing and writing the eclass and figuring out all the > different cases that should be supported, that part is done now. > But none of this does feel particularly native to Gentoo. Most of the Linux world is of binary distros, so while it may not be NIH, it somewhat is NIH wrt source distros (or can feel like that). In the same way, Eli and I have some different opinions on splitpkgs -- he's sort of convinced me that there's some utility in them, but they're in no way *as useful* as they are on primarily-binary distributions. But I don't consider myself an expert on kernel modules either, just the fact that Ionen shares my unease (or I share his) makes me feel like mine isn't unwarranted. > [...] thanks, sam
