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 C99211584F2 for ; Thu, 20 Mar 2025 08:26: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 B5FCC343337 for ; Thu, 20 Mar 2025 08:26:45 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 51DCB1103E2; Thu, 20 Mar 2025 08:26:03 +0000 (UTC) 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 bobolink.gentoo.org (Postfix) with ESMTPS id A50E211037F for ; Thu, 20 Mar 2025 08:26:02 +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 20BF83430FE for ; Thu, 20 Mar 2025 08:26:01 +0000 (UTC) Message-ID: Date: Thu, 20 Mar 2025 09:25:59 +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> <87frj8658y.fsf@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: b35ee20c-cabf-438c-ade9-b796ef5ed51a X-Archives-Hash: cb4f2f3ef9a0630ef4be62333e4409f8 On 19/03/2025 23:37, Eli Schwartz wrote: > 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. >> >> 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. > > > 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=dkms 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 Making the prepping (i.e. the creation/seding/moving of the dkms.conf files) unconditional is definitely doable. I'm not sure about calling 'dkms build' in src_install. DKMS has some switches to move around the location of the module and dkms tree that we could in theory use to have it operate on the ED instead of the EROOT. But it does expect some files to be already there. Though perhaps we could solve this with some symlinks. That being said, this would add more complexity, and we also run into the problem that sys-kernel/dkms is not keyworded everywhere (yet). Furthermore, we still keep the dkms USE flag, so fundamentally there are still two paths to test. > This would mean making dkms a dependency as such: > > BDEPEND=" > !dkms? ( sys-kernel/dkms ) > " > RDEPEND=" > dkms? ( sys-kernel/dkms ) > " > > I suppose that not everyone will necessarily like this. But it should be > technically feasible, at least. >