public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Duncan <1i5t5.duncan@cox.net>
Cc: 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 22:11:58 +0000	[thread overview]
Message-ID: <877c4k6575.fsf@gentoo.org> (raw)
In-Reply-To: <pan$a9a61$d3e73452$3476d2a9$78b1017a@cox.net>

Duncan <1i5t5.duncan@cox.net> writes:

> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>
>> I had really hoped to receive more comments on my earlier RFC. [...]
>> I really do want to know what others think so I can
>> make a better judgment on whether or not my idea is really this crazy
>> and if I should just shut up about it or not (so dear reader if you have
>> an opinion then please share).
>
> So because I carried over my own already "works for me" kernel maintenance 
> scripts from Mandrake when I switched in 2004 and have continued 
> maintaining and using them over the decades since, I normally try to stay 
> out of Gentoo kernel packaging discussion. But given both the above 
> explicit invitation and that as I've read the thread a thought occurred to 
> me...
>
> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> general it should be reasonably supported in Gentoo unless it simply 
> doesn't make sense (note that "doesn't make sense" can also include the 
> case of simply no one stepping up to do it, not the case here).
>
> But, the thought that occurred to me reading the thread, was that there 
> are obvious parallels between this and another very significant and 
> controversial now "cross distro standard solution" (which I guess I don't 
> need to name explicitly).
>
> As there, I believe "the Gentoo approach" should (again assuming developer 
> willingness to do the work, seemingly the case here) make it available as 
> an additional integrated *option*, while keeping the current Gentoo option 
> as well.
>
> So I support DKMS integration /as/ /an/ /option/.

I do generally appreciate your input, but I'll note that this email
boils down to "choice is good" (even though you're seemingly not going
to use this at all).

This is somewhat of a meme and doesn't really make sense in isolation,
given maintainability and clear documentation is always something we
have to weigh up more options with.


  parent reply	other threads:[~2025-03-19 22:12 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
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 [this message]
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=877c4k6575.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=1i5t5.duncan@cox.net \
    --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