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

[Nowa Ammerlaan <nowa@gentoo.org>]

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