Aigars Mahinovs <aigar...@gmail.com> wrote:
On 24 October 2014 12:35, Ansgar Burchardt <ans...@debian.org> wrote:
> In fact, they want to require that if P supports only A (and not A|B)
> that the maintainers of P have to patch P to make it support B. In the
> good old days[tm] it would be the responsibility of the people wanting
> to use B to submit patches to make P work with B (but here I suspect
> many people demanding support for B do not even use P[1]...).
And this is exactly why this GR is moot: it contradicts the
constitution. Even if it passes, you couldn’t force maintainers of A
(systemd) or P (GNOME, KDE, Xfce) to maintain B (systemd-shim) or fix
bugs in B.
Eventually, bugs in B would result in RC bugs in P that the release team
would have to ignore because P is too useful.
The root of the problem is coming from upstream not caring about
alternative init systems. To take the logind case as an example - each
of the dependencies from GDM to systemd make perfect sense in
isolation. However, the end result (was) that GDM only worked with
systemd almost by accident. No developer in that chain was compelled
to run this under other init systems.
However these choices heavily impact our users who (for whatever
reasons) want or need to use another init system.
No, they don’t. “Wanting another init system” is not a functional need.
It is a tantrum from people who are confronted to change resistance, but
we don’t have to cover that requirement per se.
The default init system should cover all use cases. And apart from a few
glitches that emerge from the transition, systemd does. This is why
compatibility has to be ensured in jessie, but post-jessie such a
requirement doesn’t make sense.
--
Joss
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414152127.4673.443.camel@dsp0698014
