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 F3BC81584F2 for ; Wed, 19 Mar 2025 22:38:04 +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 DDD5A34328B for ; Wed, 19 Mar 2025 22:38:04 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id EB2721103E2; Wed, 19 Mar 2025 22:37:22 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 44C6811037F for ; Wed, 19 Mar 2025 22:37:22 +0000 (UTC) Received: from [IPV6:2603:6011:3f0:6f00::12ac] (unknown [IPv6:2603:6011:3f0:6f00::12ac]) (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: eschwartz) by smtp.gentoo.org (Postfix) with ESMTPSA id C99393430D8 for ; Wed, 19 Mar 2025 22:37:21 +0000 (UTC) Message-ID: Date: Wed, 19 Mar 2025 18:37:18 -0400 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> <87frj8658y.fsf@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: <87frj8658y.fsf@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8ejJvGg0gvNveBq7INEgmXHJ" X-Archives-Salt: 8a4c7de4-0586-4e1d-a14b-78dac863fae9 X-Archives-Hash: 0ea6c29fd947c3c83b191133a96ff1c2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8ejJvGg0gvNveBq7INEgmXHJ Content-Type: multipart/mixed; boundary="------------By2Tj9x4ZSdkrbqaiRpDsZGq"; protected-headers="v1" From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public 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> <87frj8658y.fsf@gentoo.org> In-Reply-To: <87frj8658y.fsf@gentoo.org> --------------By2Tj9x4ZSdkrbqaiRpDsZGq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/19/25 6:10 PM, Sam James wrote: > 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. >=20 > I also agree with Ionen that this is important enough that I'd want thi= s > to be the primary path (and fully tested & supported), not done at > all. But wanting to support *both* long-time makes me uneasy. Shower thought, but if interested in guaranteeing a single tested path, it is possible to unconditionally prep the source tree for dkms, then have USE=3Ddkms decide whether to: - install the sources to /usr/src - build the module in the ebuild and install it in src_install, via running the `dkms build` command This would mean making dkms a dependency as such: BDEPEND=3D" !dkms? ( sys-kernel/dkms ) " RDEPEND=3D" dkms? ( sys-kernel/dkms ) " I suppose that not everyone will necessarily like this. But it should be technically feasible, at least. >> [...] >> >>>> 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. >> >=20 > 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). >=20 > 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'r= e > in no way *as useful* as they are on primarily-binary distributions. Couldn't you say the same thing about gentoo-sources? Like dkms, this entails installing source code which users will then compile and install outside of an ebuild. In fact this is one of the biggest reasons I think supporting dkms on Gentoo is important, because I can't see how one could *build* a kernel module in src_install and install it as part of CONTENTS, when you don't actually know what kernels are installed. I mean, sure, you could treat emerge as a hook program to iteratively build orphaned modules for orphaned kernels via manual non-portage steps to bamboozle emerge into thinking that's "the kernel" to use. Many things are possible, given sufficient determination. But the discussion is about what feels native and clean and "not a hack". And what seems "not a hack" to me is that if you install kernel sources, you should be able to install module sources too. > But I don't consider myself an expert on kernel modules either, just th= e > fact that Ionen shares my unease (or I share his) makes me feel like > mine isn't unwarranted. >=20 >> [...] >=20 > thanks, > sam >=20 --=20 Eli Schwartz --------------By2Tj9x4ZSdkrbqaiRpDsZGq-- --------------8ejJvGg0gvNveBq7INEgmXHJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ9tHHgUDAAAAAAAKCRCEp9ErcA0vV10U AP4/4f6u4UGBOtJKM5h15lUbBlkkDVzmD7qIjvnxSMmiGgD7BbPfLvlYky3qGO0kcaGNZ0/wihqh QF18KAZ2O/xrhwI= =CCEO -----END PGP SIGNATURE----- --------------8ejJvGg0gvNveBq7INEgmXHJ--