1 |
William Hubbs posted on Sat, 25 Feb 2012 00:01:07 -0600 as excerpted: |
2 |
|
3 |
> Also, this brings up another question. I replaced module-init-tools in |
4 |
> the system set with virtual/modutils. But, since it is possible to have |
5 |
> a linux system with a monolithic kernel, should this even be in the |
6 |
> system set? If not, once the dependencies are correct, I propose |
7 |
> dropping virtual/modutils from the system set. |
8 |
|
9 |
FWIW, I'm one of those monolithic kernel running folks. |
10 |
|
11 |
I'm also one of those folks with everything the PM installs on rootfs, so |
12 |
haven't been affected by the reason for masking newer udev and thus I |
13 |
unmasked and installed it some time ago. |
14 |
|
15 |
As such, I got udev-181 before it depended on kmod, and thus know that |
16 |
udev-181 won't build without it. |
17 |
|
18 |
Given that udev-181 requires kmod, and while udev itself isn't in the |
19 |
system set, it's the preferred dep of virtual/dev-manager, which IS in |
20 |
the system set... |
21 |
|
22 |
By udev-181, the vast majority of gentoo users who use udev WILL have kmod |
23 |
installed (and not module-init-tools, since it and kmod block each |
24 |
other), system-set, other dependency, or not, simply due to udev. |
25 |
|
26 |
As such, IMO virtual/modutils doesn't need to be in the system set, |
27 |
because udev pulls it in. |
28 |
|
29 |
Since most users have udev (and it's part of the stage-3 as the preferred |
30 |
dev-manager), they'll have kmod as a dependency and given its default- |
31 |
USE, they'll normally have the module-init-tools compatibility symlinks, |
32 |
so module handling will work as it always has, for them. |
33 |
|
34 |
As such, I disagree with floppym that the handbook's kernel module |
35 |
section needs updating for this, too. The handbook doesn't even deal |
36 |
with non-default dev-managers, nor does it mention module-init-tools, it |
37 |
just assumes it's there. Udev, as the default dev-manager, will be |
38 |
pulling in kmod already, with its default module-init-tools compatibility |
39 |
meaning no change in documentation necessary. Only if we're going to |
40 |
start giving users dev-manager alternatives in the handbook does it |
41 |
become an issue, and while that would be nice, I don't think it's |
42 |
necessary for this change. |
43 |
|
44 |
That leaves those using a dev-manager other than udev in a current |
45 |
installation who are depending on the current system set listing to bring |
46 |
in module-init-tools. I believe busybox has it's own modutils as well, |
47 |
doesn't it, so that eliminates them. Similarly, the fbsd folks aren't |
48 |
likely to be using Linux module-init-tools, right? |
49 |
|
50 |
That leaves those still using kernel 2.4 and devfsd, and those using |
51 |
static-dev. |
52 |
|
53 |
Is kernel 2.4 and devfsd still a supported option? If not, that pretty |
54 |
much eliminates it. If it /is/ still supported, maybe this can be our |
55 |
excuse to drop it? Is that feasible, or are there users, perhaps on some |
56 |
of the supported exotic archs, for which kernel 2.6 and udev, etc, is not |
57 |
a viable option? |
58 |
|
59 |
That means the static-dev folks, and possibly some still on 2.4 and devfs, |
60 |
if that's even still supported. Static-dev could arguably pull in |
61 |
modultils as a dependency, or a news item could be created that triggered |
62 |
on static-dev installed. Similarly for devfsd, if it's still supported. |
63 |
|
64 |
> On the other hand, if we want virtual/modutils in the system set, there |
65 |
> should be no dependencies in the tree on virtual/modutils. |
66 |
|
67 |
Good point. Hopefully, tho, it can simply be removed from the system set. |
68 |
|
69 |
-- |
70 |
Duncan - List replies preferred. No HTML msgs. |
71 |
"Every nonfree program has a lord, a master -- |
72 |
and if you use the program, he is your master." Richard Stallman |