Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens <ionen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

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.

And looking at ebuilds in the PR, fair amount of ebuilds now have
extra `use dkms` logic to consider and not fully transparently handled
by the eclass. I'd rather see this dropped in the future to support
only one way whichever it is.

> 
> 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?

...not that I feel the dkms way is the right one (for us).

> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]