| 1 |
Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: |
| 2 |
|
| 3 |
>>> Having a builtin is a good idea, but the implementation as a mandatory |
| 4 |
>>> dependency on kmod is not. The plan is to reintroduce it as an |
| 5 |
>>> optional dependency, so that distributions (and Gentoo users) that do |
| 6 |
>>> not want it can avoid it. None of us want to force dependencies on |
| 7 |
>>> others and there is no need for this one. |
| 8 |
>> |
| 9 |
>> You do realize that you didn't really drop the dependency at all, |
| 10 |
>> right? |
| 11 |
> |
| 12 |
> kmod does not exist on my system and eudev builds without a problem. I |
| 13 |
> am thinking of writing my own busybox-style code to handle module |
| 14 |
> loading in the builtin when the configure script is told not to build |
| 15 |
> with kmod. Does this not avoid the dependency? |
| 16 |
|
| 17 |
FWIW... |
| 18 |
|
| 19 |
I run a monolithic kernel here, no modules /to/ load. As a result, for |
| 20 |
quite some time I had module-init-tools in package.provided, because I |
| 21 |
really didn't need it at all. |
| 22 |
|
| 23 |
Then udev switched to kmod as a build-time dep. I could no longer |
| 24 |
package.provide kmod as I had module-init-tools, because it was required |
| 25 |
to /build/ udev. For no valid reason on my system. Like any unnecessary |
| 26 |
feature that can be used to load an exploit, it's worse than useless. |
| 27 |
But it was required to build, just because someone decided people had no |
| 28 |
valid reason to run a monolithic kernel system any longer, and that |
| 29 |
people who did so apparently no longer mattered, udev-wise. |
| 30 |
|
| 31 |
That's only one such decision of a whole list following a similar |
| 32 |
pattern, simply deciding that some segment of the Linux-using populace or |
| 33 |
another no longer matters, because it's not the segment that the udev |
| 34 |
folks are focused on. In many cases, they've already said they're not |
| 35 |
interested in patches resolving the issues, too. Thus, no, submitting |
| 36 |
the patches for inclusion upstream isn't working. Seems reason enough |
| 37 |
for a fork, to me. |
| 38 |
|
| 39 |
Back on subtopic, yes, I'm definitely interested in a udev fork that |
| 40 |
doesn't force the otherwise useless on my systems kmod as a build-time |
| 41 |
dep. package.provided worked for years as a workaround for the module- |
| 42 |
init-tools @system dep. And I'd like to get back to not having to have a |
| 43 |
module-loader package installed at all, since I don't have any modules to |
| 44 |
load anyway. |
| 45 |
|
| 46 |
-- |
| 47 |
Duncan - List replies preferred. No HTML msgs. |
| 48 |
"Every nonfree program has a lord, a master -- |
| 49 |
and if you use the program, he is your master." Richard Stallman |
Archives