On Sun, Nov 18, 2012 at 12:06 AM, Duncan <1i5t5.dun...@cox.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/
