| 1 |
On Wed, Dec 21, 2016 at 7:09 AM, <karl@××××××××.se> wrote: |
| 2 |
> |
| 3 |
> The problem is that an ever increasing amount of programs list systemd |
| 4 |
> or some of its libs as a depenancy. So it is getting harder and harder |
| 5 |
> to opt out. |
| 6 |
> |
| 7 |
> The situation is similar to the one with udev and variants. Some |
| 8 |
> programs list udev as a requirement even though there is no requirment |
| 9 |
> on technical grounds. I.e. X, I can run X perfectly without udev, I |
| 10 |
> just have to make my own xorg.conf, or I might want to run X with udev |
| 11 |
> since then it handles multiple keyboards with different layouts |
| 12 |
> automatically. It's like when buying a car, some prefer automats, some |
| 13 |
> stick shift. There are pro and cons for both cases. |
| 14 |
> |
| 15 |
|
| 16 |
I get your frustration. |
| 17 |
|
| 18 |
Below is just my personal sense of things, ultimately the entire |
| 19 |
Council sets policy but this is my sense of the "Gentoo Way" and how I |
| 20 |
see things being likely to go. |
| 21 |
|
| 22 |
On Gentoo at a distro level we're never going to force package |
| 23 |
maintainers to make any particular package a dependency as long as the |
| 24 |
software works without it. At the same time we're not going to force |
| 25 |
maintainers to patch software to eliminate dependencies. We certainly |
| 26 |
encourage maintainers to do things like this within reason, but we |
| 27 |
don't require it. |
| 28 |
|
| 29 |
In your example, if upstream xorg starts sticking dbus calls to |
| 30 |
udev/systemd/etc in their code, and it fails to launch if those |
| 31 |
packages aren't running, then unless somebody patches out that |
| 32 |
behavior or makes it conditional then udev/systemd would need to be |
| 33 |
listed as dependencies. It isn't like simply not listing them would |
| 34 |
fix the issue anyway, it would just cause X to fail to launch for some |
| 35 |
users. |
| 36 |
|
| 37 |
When software just runs without some features without another package |
| 38 |
installed, then there is no requirement to list it as a dependency |
| 39 |
(generally speaking). Maybe during the install it might suggest |
| 40 |
installing some other packages for full functionality. |
| 41 |
|
| 42 |
In the end though, if xorg requires systemd as shipped upstream, that |
| 43 |
is an upstream issue. I realize you'll get a lot less sympathy with |
| 44 |
many upstream projects than you'll get around here because |
| 45 |
goals/philosophies differ. |
| 46 |
|
| 47 |
And as upstream projects go further down that road, it will in |
| 48 |
practice become more difficult for a distro like Gentoo to maintain |
| 49 |
larger and larger patches to alter their behavior. Gentoo as a distro |
| 50 |
will probably never force a developer to give up, but at some point |
| 51 |
you're talking about maintaining a fork and not a patch. Now, you can |
| 52 |
look at eudev and see that there is ultimately no limit on how long |
| 53 |
that can go on, but it depends on people willing to do the work. |
| 54 |
|
| 55 |
Ultimately Gentoo is a place where we all come together to try to |
| 56 |
support our ability to maintain a diverse configuration space. Still, |
| 57 |
that diversity largely depends on the interests of those who put in |
| 58 |
the work to maintain it. And it often comes at a cost of less |
| 59 |
vertical integration and automation. At a distro level we try to |
| 60 |
remove barriers to individual contribution, not force individuals to |
| 61 |
contribute in a manner that we would prefer them to. |
| 62 |
|
| 63 |
-- |
| 64 |
Rich |
Archives