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.
