Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

In some sense I am asking the same questions as Russ.

Guillem Jover writes ("Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)"):
> I've to say, that while I think I understand where your and other similar
> reactions to this proposal are coming from, I also found them a bit
> perplexing. :)

Let me skip to the end:

> The key here, I guess, is that each situation needs to be evaluated
> independently, and no magic decision tree will ever fix trying to work
> things out with other people, in good faith, and trying to find
> solutions or compromises that satisfy others and us too. But maybe this
> is asking too much, dunno. :/
> 
> I understand that not giving apparently detailed guidance might make
> things more difficult for the policy editors, and I'm sorry about that,
> but I think no one ever expected that collaborating in a project such as
> Debian with people pulling in random directions would always be easy?

As you know I very much agree with you about the framing.

But it appears that you don't that we should then, in something like
your proposal, take the principles in that framing and apply them in
to some of the most contentious specific problems facing us today.

In its current state I think your proposal is unlikely to do well.
I am very keen that something with your framing text should do well.

Since you don't seem to agree that your option should be supplemented
by specifics, I would like to ask the rest of the community:

* Should I adopt Guillem's framing as a preamble to my own proposal ?
  (Should this be a new alternative or a replacement?)

* Would Guillem's framing make a good preamble to Dmitry's option ?

* Or do the supporters of Guillem's option favour some other
  combination of possible answers to the specific questions ?

I think they key specific questions are:

Q1 Init scripts.  Possible answers, roughly:

 E  Lack of an init script is an RC bug; maintainers must write
    init scripts.

 D  Lack of an init script is not an RC bug but contributions of init
    scripts should be filed as RC bugs.  Ie the non-systemd community
    must write them but maintainers must accept them.

 All other options [1]
    Lack of an init script is a normal or wishlist bug and
    maintainers can block them because they want systemd
    hegemony.

Q2 sysusers.d, systemd timer units, etc.

 E  May not be used (RC bug) unless a non-systemd-pid-1
    implementation is available.  Ie proponents of these
    interfaces must write the non-systemd variant.

 D  Can be standardised in policy and used but only if they (i) are
    any good (ii) can sensibly exist for non-systemd.  Ie, the
    non-systemd community must write the non-systemd variant, but they
    will get the time to do so.

 All other options [1]
    Everyone is allowed to use them willy-nilly and non-systemd
    support will rot.

Q3 dependencies which cause init system switching etc.

 E,D
    Forbiddden

 All other options [1]
    Allowed.  Theoretical degradations of dependencies on systemd
    systems will continue to make it really hard to install and
    maintain non-systemd ones.

I have written this mail To people who seconded Guillem's proposal and
to some people from the thread.  I would particularly like to hear
your views.

I am considering making a formal variant of Guillem's proposal, which,
if Guillem doesn't agree that specific guidance is needed, would stand
on the ballot alongside Guillem's and my proposal D.  I would like
that proposal to reflect the views of people who seconded Guillem's
proposal.

Thanks
Ian.

[1] Sam's B "Support for multiple init systems is Important" appears
to allow NMUs to provide init scripts and to use alternatives to
systemd facilities but it says "According to the NMU guidelines".  The
NMU guidelines forbid NMUs when the maintainer has explicitly said
they do not want a particular change.  So in practice a maintainer who
does not want an init script in their package can block this and the
only possible recourse is to the TC, which is not suitable and not
effective.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.