From: Eli Schwartz <eschwartz@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public
Date: Wed, 19 Mar 2025 18:37:18 -0400 [thread overview]
Message-ID: <ffe331ac-ba0c-42fa-86d4-4e897f1b43e3@gentoo.org> (raw)
In-Reply-To: <87frj8658y.fsf@gentoo.org>
[-- Attachment #1.1: Type: text/plain, Size: 3530 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2025-03-19 22:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 12:48 [gentoo-dev] [PATCH 1/5] use.desc: document new dkms flag Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 2/5] profiles: mask dkms flag where not available Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 3/5] linux-mod-r1.eclass: move modlist processing into separate func Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public Nowa Ammerlaan
2025-03-14 16:23 ` Ionen Wolkens
2025-03-14 19:47 ` Nowa Ammerlaan
2025-03-15 3:56 ` Ionen Wolkens
2025-03-17 10:11 ` Nowa Ammerlaan
2025-03-17 10:25 ` Alexey Sokolov
2025-03-18 3:14 ` [gentoo-dev] " Duncan
2025-03-19 0:34 ` Ionen Wolkens
2025-03-19 0:56 ` Ionen Wolkens
2025-03-19 1:07 ` Ionen Wolkens
2025-03-19 7:57 ` Nowa Ammerlaan
2025-03-19 8:48 ` Ionen Wolkens
2025-03-19 12:41 ` Nowa Ammerlaan
2025-03-19 22:10 ` Sam James
2025-03-19 22:37 ` Eli Schwartz [this message]
2025-03-20 8:25 ` Nowa Ammerlaan
2025-03-20 8:12 ` Nowa Ammerlaan
2025-03-19 3:05 ` Ionen Wolkens
2025-03-19 22:11 ` Sam James
2025-03-17 16:23 ` [gentoo-dev] " Eli Schwartz
2025-03-14 12:48 ` [gentoo-dev] [PATCH 5/5] dkms.eclass: introduce new eclass Nowa Ammerlaan
2025-03-14 15:34 ` Alexey Sokolov
2025-03-14 15:44 ` Nowa Ammerlaan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffe331ac-ba0c-42fa-86d4-4e897f1b43e3@gentoo.org \
--to=eschwartz@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox