Gentoo Archives: gentoo-dev

From: Vaeth <vaeth@××××××××××××××××××××××××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?
Date: Wed, 29 Aug 2012 15:13:23
Message-Id: alpine.LNX.2.00.1208291711070.25811@wma7001.mathematik.uni-wuerzburg.de
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.

Replies