Re: Tentative summary of the amendments
- To: debian-vote@lists.debian.org
- Subject: Re: Tentative summary of the amendments
- From: Josh Triplett <josh@joshtriplett.org>
- Date: Fri, 24 Oct 2014 05:42:53 -0700
- Message-id: <20141024124252.GA16760@thin>
- In-reply-to: <20141024124026.GA16686@thin>
- References: <CABpYwDVH=uN5eoe5UTqWQt+E7ukF-+vrZYKz=xc5woL6h09HCw@mail.gmail.com> <20141024124026.GA16686@thin>
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
Reply to: