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 B01C01584F2 for ; Wed, 19 Mar 2025 03:06:45 +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 9A007343314 for ; Wed, 19 Mar 2025 03:06:45 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 1BC0E1103E2; Wed, 19 Mar 2025 03:06:03 +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)) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 6030C11037F for ; Wed, 19 Mar 2025 03:06:02 +0000 (UTC) Received: from eversor (unknown [24.157.215.217]) (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: ionen) by smtp.gentoo.org (Postfix) with ESMTPSA id EB3EF3430FE for ; Wed, 19 Mar 2025 03:06:01 +0000 (UTC) Date: Tue, 18 Mar 2025 23:05:59 -0400 From: Ionen Wolkens To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public Message-ID: Mail-Followup-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> 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PnvUnC0iKbfSKmK0" Content-Disposition: inline In-Reply-To: X-Archives-Salt: dbf61d27-b745-4d43-b10f-4a1ea2d32472 X-Archives-Hash: 472a973e05b0009d3a0d382b13f45ccc --PnvUnC0iKbfSKmK0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > 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 h= ave > > > an opinion then please share). > >=20 > > So because I carried over my own already "works for me" kernel maintena= nce=20 > > scripts from Mandrake when I switched in 2004 and have continued=20 > > maintaining and using them over the decades since, I normally try to st= ay=20 > > out of Gentoo kernel packaging discussion. But given both the above=20 > > explicit invitation and that as I've read the thread a thought occurred= to=20 > > me... > >=20 > > First, DKMS /is/ a cross-distro standard solution. As such, I believe = in=20 > > general it should be reasonably supported in Gentoo unless it simply=20 > > doesn't make sense (note that "doesn't make sense" can also include the= =20 > > case of simply no one stepping up to do it, not the case here). > >=20 > > But, the thought that occurred to me reading the thread, was that there= =20 > > are obvious parallels between this and another very significant and=20 > > controversial now "cross distro standard solution" (which I guess I don= 't=20 > > need to name explicitly). > >=20 > > As there, I believe "the Gentoo approach" should (again assuming develo= per=20 > > willingness to do the work, seemingly the case here) make it available = as=20 > > an additional integrated *option*, while keeping the current Gentoo opt= ion=20 > > as well. > >=20 > > So I support DKMS integration /as/ /an/ /option/. >=20 > 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. >=20 > 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. >=20 > It's nice to have choices in general, but still need to draw some > lines to keep things maintainable. >=20 > 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? =2E..not that I feel the dkms way is the right one (for us). >=20 > 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. >=20 > 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. >=20 > 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). --=20 ionen --PnvUnC0iKbfSKmK0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmfaNJcACgkQskQGsLCs QzQAEQgAvGF91JB/t3roEq8Ru34C4Souc/KGLAB0ehSkxajYk5P2qIPnGql/XvTt Qow/6bfyvIsLzXEfGh9uQM94OZruEI21LaeT8pzZTzbQSwbNRjhpsjLI+8JhOX0K LjnKppD3pXi8HebfsKoH3j7ogK+m6nNp8jP3GJCD3rP27jnrg8/qZ3gRd9xVxRLA CzClGnk/cWhqaqQ1uBNFtnHOWf2kOVvxKPgPy5OxFxyDiSytt4YqFtfSGTNTwQ8B MRtuZZfg6JY3BOz+JlCQCZLyMQMmDxp/jPtSm3YtQRee2JMuOaCmQQ7RmiGMfyET r4hsIugD73WKwuJcsIkWzFeWqZ6odw== =8ewg -----END PGP SIGNATURE----- --PnvUnC0iKbfSKmK0--