Re: Tentative summary of the amendments

[Josh Triplett <josh@joshtriplett.org>]

Ansgar Burchardt wrote:
> 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.

We have not, historically, banned packages from introducing dependencies
on specific (FOSS) software they use, particularly in the absence of
patches implementing alternative dependencies.  Imagine if we said "The
root of the problem is coming from upstream not caring about alternative
libc implementations.", and started complaining at packages that won't
build with newlib?  Sure, many people have very legitimate reasons to
want to run some packages with a smaller libc implementation; however,
the burden remains firmly on them to make that work, and the project
cannot force maintainers of arbitrary packages to care about non-glibc.

We have a substantial number of packages in Debian that depend
specifically on a Linux kernel, or even on specific architectures.
While there are people working to port those packages to alternative
kernels such as the Hurd and *BSD, I don't see anyone calling for a GR
to force packages to support alternative kernels; instead, I see the
people who care about running those kernels actually doing an impressive
amount of work to write patches.  Similarly, even for packages that do
code generation (such as compiled programming languages), and thus only
support specific architectures, people have actually done the
substantial amount of work to add additional architecture support.

What makes the systemd case so drastically different that those who care
about alternative init systems cannot follow the same procedure?

> However these choices heavily impact our users who (for whatever
> reasons) want or need to use another init system. Such users are used
> to having to write an odd init script for some service - that is an
> acceptable extra work for using a non-default init system. However it
> is a much harder task to have to implement a new API introduced by
> systemd or creating something like systemd-shim. We should not be
> pushing such burdens to our users. That is too hard a punishment for
> using an alternative init system and also upstream (or maintainer) are
> far better positioned to implement some workaround to make the
> software work with alternative inits.

Upstream and the maintainer don't necessarily *care*.  A GR will not
make them care.  As a user, if you want something that does not exist,
you file a wishlist bug and you hope to find someone willing to
implement it for you, or you work to convince people to care.

(And to provide a bit of contrast here, several upstreams are making a
substantial effort to continue supporting alternate init systems even
when not doing so would be far easier and more fun.  The near-complete
absence of any real examples in Debian of packages that currently
*don't* support sysvinit or that refuse to accept patches makes the
arguments surrounding this issue ring rather hollow.)

- Josh Triplett