Bug#727708: init system coupling etc.
On 2014-02-14 13:50:20 +0000, Ian Jackson wrote:
> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > In all cases, it is unacceptable to put the burden of implementing
> > logind on non-systemd systems on maintainers of packages that just need
> > the logind interfaces. If it is not available, software such as gdm3
> > will depend, directly or indirectly, on systemd as PID 1, and that will
> > be all.
>
> Firstly, I think the scenario where the required integration work is
> not done is unlikely. But in that scenario, we have two choices:
> (a) Effectively, drop all init systems other than systemd
> (b) Effectively, drop GNOME
>
> Of these, (b) is IMO clearly preferable. Our downstreams can
> straightforwardly provide a more specific Debian derivative which runs
> GNOME and (only) systemd. Asking our downstreams to reintroduce
> support for a non-systemd init system is not feasible.
> With (b) people who want GNOME and systemd can do that work as a
> Debian derivative; it is not necessary to fork the whole project.
I don't think b) would have any upsides, even if it's only happening for
a short time:
a) Debian users would loose because the DE (gnome and some others) the
use vanishes. We've seen how happy changes around that makes them,
and how vocal they can get. Surely entirely removing a DE entirely
makes them even more unhappy than substantive change.
b) Debian would loose users.
c) downstreams would suffer, because they now would need to package
$software independently from debian. Collaboration without a common
upstream is hard.
d) Parties wanting to port/test a piece of software to work without
systemd, suddenly need to care about packaging, before their real
work can start. Individual developers maybe can get by using source
code checkouts and compiling everything themselves, but testers
surely not.
e) Parties wanting to implement alternatives to systemd's logind, cgroup
manager have less software to test.
Given those points the only value in suggesting that route is in being a
threat gesture against some unspecified party. I think such a gesture is
of questionable morality, but even worse, I think it runs counter to
your goals of having most software run independently of the init
system.
I don't see this helping the freedom of debian's users, rather the
contrary.
I think it makes much more sense to generate policy or a TC statement,
that suggests that packagers should apply reasonable patches to help
portability (just like they are already asked for porting software to
some different linux or other supported architecture). And, quite
importantly, try to streamline the process of dealing with escalations
to the TC to determine whether a patch is reasonable. If that takes half
a year every now and then most people will just give up.
Regards,
Andres Freund
Reply to: