Re: Tentative summary of the amendments

[Josh Triplett <josh@joshtriplett.org>]

On Fri, Oct 24, 2014 at 05:40:28AM -0700, Josh Triplett wrote:
> Ansgar Burchardt wrote:

My apologies, that should have been:

> Aigars Mahinovs wrote:

(The web archives on lists.debian.org have reply-to links, but those
links don't include quoted mail text as the BTS links do; I copy-pasted
the wrong name when constructing the attribution.)

> > 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