From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 71A6D1584F2 for ; Wed, 19 Mar 2025 12:42:18 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 5E0F734333A for ; Wed, 19 Mar 2025 12:42:18 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 17E6B1103E2; Wed, 19 Mar 2025 12:41:36 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 4BE3E11037F for ; Wed, 19 Mar 2025 12:41:35 +0000 (UTC) Received: from [IPV6:2a02:a45a:ca9b::aa5] (2a02-a45a-ca9b--aa5.fixed6.kpn.net [IPv6:2a02:a45a:ca9b::aa5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nowa) by smtp.gentoo.org (Postfix) with ESMTPSA id ACBDD343137 for ; Wed, 19 Mar 2025 12:41:34 +0000 (UTC) Message-ID: <8042275e-57a0-410d-adac-c0f4b65e6225@gentoo.org> Date: Wed, 19 Mar 2025 13:41:32 +0100 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public To: gentoo-dev@lists.gentoo.org References: <20250314124851.716771-1-nowa@gentoo.org> <20250314124851.716771-4-nowa@gentoo.org> <655147fe-ed05-4b09-9f73-c1765fe6c841@gentoo.org> <487ddd00-aabe-4c9b-a312-a541a1ef61f1@gentoo.org> <8ab1cf07-f703-4212-825b-188e4760b306@gentoo.org> Content-Language: en-US, nl-NL From: Nowa Ammerlaan Organization: Gentoo Linux In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 5945daa5-1000-4588-8331-911370ff70a6 X-Archives-Hash: 83249656885e7332a734352f330ac111 On 19/03/2025 09:48, Ionen Wolkens wrote: > On Wed, Mar 19, 2025 at 08:57:38AM +0100, Nowa Ammerlaan wrote: >> 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. >> >> I'll also note again that Nvidia is one of the upstreams that supports >> DKMS, in contrast to our own linux-mod-r1 solution in portage which I >> don't think they care about at all. I'd therefore say that it is far >> more likely for Nvidia to change something that breaks the existing >> non-dkms pathway in the ebuild, then it is for them to break the dkms >> pathway that lots of other distributions rely on. >> >>>> 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. >> >>>> 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. >> >> The main reason this is in a separate eclass is because we need a >> pkg_prerm for dkms that linux-mod-r1 does not have. And as you pointed >> out earlier, exporting an extra phase function in an established eclass >> is not a good idea. > > Yes, but it could've either have become a linux-mod-r2 (and deprecate > -r1 eventually) or done on EAPI bump in the future. > > I don't really see why any ebuilds should inherit linux-mod-r1 right > now when they'll just be the odd one out if they don't support dkms. > May as well merge it into dkms.eclass and get rid of it after consumers > are gone. We can still do that (i.e. merge it all into one eclass named linux-mod-r2 instead of inheriting linux-mod-r1), but from our earlier discussion it was my impression that this is not what you wanted. We could even add dkms as a separate eclass now, and then merge it back into a possible linux-mod-r2 in the future (if/when there are other things we want to do that warrant a revision bump such as the multi-build approach that you suggested before). > On that note, please just take over linux-mod-r1 maintenance if merge > this so that I won't have to care anymore. Ionen, I'm getting the impression that you're taking what I said a bit personally. It is not my intention to attack you or your work, on the contrary. I may argue (too) passionately, but that is because I believe I am right and I am still trying to convince you of this because I'd rather not merge this in if you are strongly opposed. Now I am happy to co-maintain linux-mod-r1 (or -r2 if that is the route we want to take), as you know I've already submitted a number of patches for it before because it intersects closely with the dist-kernel eclasses. That being said, I do not wish to usurp your position here. Best regards, Nowa