Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Matt Turner]

On Sun, Nov 18, 2012 at 12:06 AM, Duncan <1i5t5.duncan@×××.net> wrote:
> Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted:
>
>>>> Having a builtin is a good idea, but the implementation as a mandatory
>>>> dependency on kmod is not. The plan is to reintroduce it as an
>>>> optional dependency, so that distributions (and Gentoo users) that do
>>>> not want it can avoid it. None of us want to force dependencies on
>>>> others and there is no need for this one.
>>>
>>> You do realize that you didn't really drop the dependency at all,
>>> right?
>>
>> kmod does not exist on my system and eudev builds without a problem. I
>> am thinking of writing my own busybox-style code to handle module
>> loading in the builtin when the configure script is told not to build
>> with kmod. Does this not avoid the dependency?
>
> FWIW...
>
> I run a monolithic kernel here, no modules /to/ load.  As a result, for
> quite some time I had module-init-tools in package.provided, because I
> really didn't need it at all.
>
> Then udev switched to kmod as a build-time dep.  I could no longer
> package.provide kmod as I had module-init-tools, because it was required
> to /build/ udev.  For no valid reason on my system.  Like any unnecessary
> feature that can be used to load an exploit, it's worse than useless.
> But it was required to build, just because someone decided people had no
> valid reason to run a monolithic kernel system any longer, and that
> people who did so apparently no longer mattered, udev-wise.
>
> That's only one such decision of a whole list following a similar
> pattern, simply deciding that some segment of the Linux-using populace or
> another no longer matters, because it's not the segment that the udev
> folks are focused on.  In many cases, they've already said they're not
> interested in patches resolving the issues, too.  Thus, no, submitting
> the patches for inclusion upstream isn't working.  Seems reason enough
> for a fork, to me.
>
> Back on subtopic, yes, I'm definitely interested in a udev fork that
> doesn't force the otherwise useless on my systems kmod as a build-time
> dep.  package.provided worked for years as a workaround for the module-
> init-tools @system dep.  And I'd like to get back to not having to have a
> module-loader package installed at all, since I don't have any modules to
> load anyway.

# du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/
240K	/var/tmp/portage/sys-apps/kmod-11-r1/image/