[gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Duncan]

William Hubbs posted on Sat, 25 Feb 2012 00:01:07 -0600 as excerpted:

> Also, this brings up another question. I replaced module-init-tools in
> the system set with virtual/modutils.  But, since it is possible to have
> a linux system with a monolithic kernel, should this even be in the
> system set? If not, once the dependencies are correct, I propose
> dropping virtual/modutils from the system set.

FWIW, I'm one of those monolithic kernel running folks.

I'm also one of those folks with everything the PM installs on rootfs, so 
haven't been affected by the reason for masking newer udev and thus I 
unmasked and installed it some time ago.

As such, I got udev-181 before it depended on kmod, and thus know that 
udev-181 won't build without it.

Given that udev-181 requires kmod, and while udev itself isn't in the 
system set, it's the preferred dep of virtual/dev-manager, which IS in 
the system set...

By udev-181, the vast majority of gentoo users who use udev WILL have kmod 
installed (and not module-init-tools, since it and kmod block each 
other), system-set, other dependency, or not, simply due to udev.

As such, IMO virtual/modutils doesn't need to be in the system set, 
because udev pulls it in.

Since most users have udev (and it's part of the stage-3 as the preferred 
dev-manager), they'll have kmod as a dependency and given its default-
USE, they'll normally have the module-init-tools compatibility symlinks, 
so module handling will work as it always has, for them.

As such, I disagree with floppym that the handbook's kernel module 
section needs updating for this, too.  The handbook doesn't even deal 
with non-default dev-managers, nor does it mention module-init-tools, it 
just assumes it's there.  Udev, as the default dev-manager, will be 
pulling in kmod already, with its default module-init-tools compatibility 
meaning no change in documentation necessary.  Only if we're going to 
start giving users dev-manager alternatives in the handbook does it 
become an issue, and while that would be nice, I don't think it's 
necessary for this change.

That leaves those using a dev-manager other than udev in a current 
installation who are depending on the current system set listing to bring 
in module-init-tools.  I believe busybox has it's own modutils as well, 
doesn't it, so that eliminates them.  Similarly, the fbsd folks aren't 
likely to be using Linux module-init-tools, right?

That leaves those still using kernel 2.4 and devfsd, and those using 
static-dev.

Is kernel 2.4 and devfsd still a supported option?  If not, that pretty 
much eliminates it.  If it /is/ still supported, maybe this can be our 
excuse to drop it?  Is that feasible, or are there users, perhaps on some 
of the supported exotic archs, for which kernel 2.6 and udev, etc, is not 
a viable option?

That means the static-dev folks, and possibly some still on 2.4 and devfs, 
if that's even still supported.  Static-dev could arguably pull in 
modultils as a dependency, or a news item could be created that triggered 
on static-dev installed.  Similarly for devfsd, if it's still supported.

> On the other hand, if we want virtual/modutils in the system set, there
> should be no dependencies in the tree  on virtual/modutils.

Good point.  Hopefully, tho, it can simply be removed from the system set.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman