1i5t5.duncan at cox
Feb 25, 2012, 12:28 AM
Post #4 of 10
William Hubbs posted on Sat, 25 Feb 2012 00:01:07 -0600 as excerpted:
Re: rfc: virtual/modutils and module-init-tools
[In reply to]
> 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
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