1 |
> I doubt that most people consider udev's stand-alone build-time a big |
2 |
> issue. |
3 |
|
4 |
The real issue is not the build-time but the dependencies needed |
5 |
at build-time (and in future versions perhaps also at run-time): |
6 |
Currently, these are essentially libcap and dbus. |
7 |
|
8 |
Now that some projects (e.g. hardened and overlayfs) plan to use |
9 |
extended attributes systematically, there is probably no other |
10 |
way for most users than to enable them on for file systems. |
11 |
In this case, it is a security issue (KISS principle) to have |
12 |
libcap installed. |
13 |
|
14 |
dbus alone is not a security issue yet if you do not have any *kit |
15 |
listening to it, but judging by the previous behavior of upstream, |
16 |
I would not be surprised if in the not-so-far future they will |
17 |
invent a reason to make *kit or even essential gnome libraries a |
18 |
build-time (or even run-time) dependency - of course, making |
19 |
this dependency non-optional like they do now with libcap and dbus. |
20 |
|
21 |
Currently, Gentoo is the only distribution which can provide |
22 |
the user a possibility to run a decent system without bloat |
23 |
by means of useflags. |
24 |
If upstream wants to undermine this freedom and if there is |
25 |
a possibility to give the choice back to the user by an udev virtual |
26 |
supporting the fork, I think that Gentoo should take this route: |
27 |
|
28 |
Gentoo now can show its real strength, because it is one of the |
29 |
few distributions which have technically the ability to leave |
30 |
the choice between gnome os and traditional linux to the user. |
31 |
|
32 |
If later on the divergence between the udev implementations is |
33 |
too high and nobody works on a compatibility layer, some |
34 |
dependencies on the non-virtual udev might be introduced. |
35 |
|
36 |
This is not worse than the situation which we have currently where |
37 |
also several packages cannot be used if e.g. *kit should be |
38 |
avoided. |