The Wanderer <wande...@fastmail.fm> writes:
> On 09/08/2014 at 05:46 PM, lee wrote:
>
>> Rob Owens <row...@ptd.net> writes:
>>
>>> I'm smart enough to understand that a desktop environment (or a
>>> cd burner) depending on a particular init system doesn't make
>>> sense. But I have not yet figured out which package to file a bug
>>> with. I suspect the package maintainers are smart enough to
>>> realize this as well, but maybe they have not noticed this
>>> unreasonable dependency is a result of their choices.
>>>
>>> So what should be our plan to get this addressed?
>>
>> It would seem kinda logical to file the bug against the cd-burning
>> software because it depends on an init system.
>>
>> However, this is probably a more general issue in that a yet
>> unknown amount of packages suddenly somehow depends on a particular
>> init system. So it would seem better to file a general meta-bug,
>> like John suggests.
>
> I would argue that the bug lies in the fact that this functionality
> (which software not part of an init system wants to depend on) is being
> provided by an init system.
Has it ever mattered so much /which/ software provides a functionality
that it is a bug that a software provides a functionality other software
depends on, and thus depends on the software providing the
functionality?
> IOW, it's a bug in systemd itself - more specifically, a design bug. As
> such, it should be fixed there, by moving this functionality outside of
> systemd (and making systemd depend on the external provider of the
> functionality).
You could argue that it isn't a design bug when systemd has a component
which provides a functionality needed by systemd or other components of
it. That there may be other software depending on the same
functionality is a problem with the other software.
> Unfortunately, the systemd designers and developers almost certainly
> disagree that this is a bug. They've been moving in the direction of
> more integration, not less, and AIUI have explicitly stated that patches
> removing the dependencies among the major systemd components will be
> rejected; they would almost certainly reject the idea of moving this
> functionality outside of systemd.
>
> That's not incompatible with the "single writer, single hierarchy"
> cgroups model that has apparently been mandated by the kernel upstream,
> as far as I can see; you still have one single writer managing a single
> hierarchy of cgroups, it's just that that writer is not part of PID 1,
> and does not rely on any particular PID 1 being active.
>
> However, I suspect that it would still be rejected, on fragility grounds
> if nothing else. I can still hope that I'm wrong about that, but I don't
> think it's very likely.
Maybe this bug isn't something that could be filed against a particular
package. It's more like all the involved packages are doing their thing
right under the given circumstances, yet the outcome is a problem
("bug") because it means that a (great amount of) arbitrary packages
which, by their nature or considering what they provide, are not at all
related to an init system come to depend on a particular init system.
The given circumstances need to change so that all packages can do their
thing right *without* the outcome being a problem/bug.
All Linux distributions depending on systemd are broken by design.
Debian has, perhaps unconsciously, decided that it wants to be broken by
design.
Unconsciously or not, Debian providing a distribution which is broken by
design IMHO clearly violates Debians' social contract. Otherwise you
would have to assume that the users want or need a distribution which is
broken by design and that such a distribution could still be of high
quality.
--
Knowledge is volatile and fluid. Software is power.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761gw62uy....@yun.yagibdah.de
