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
