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
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.
>> [...]
>>
>>>> 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.
>>
>
> 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).
>
> 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're
> 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 the
> fact that Ionen shares my unease (or I share his) makes me feel like
> mine isn't unwarranted.
>
>> [...]
>
> thanks,
> sam
>
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
