Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett <josh@joshtriplett.org>]

Anthony Towns wrote:
> On 29 January 2014 21:13, Colin Watson <cjwatson@debian.org> wrote:
> > On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> >> >   Q2: Is it OK for packages to depend on a specific init system as
> >> >   pid 1 ?
> >>   Q2a: Is it OK for packages providing init systems to provide other
> >> APIs beyond just the minimum needed for starting/stopping services?
> > We might disagree on the extent, perhaps, but I doubt anyone on the
> > committee would vote against this in its general form;
> 
> So looking at the votes today, I would have said that both Ian and
> Andi's original votes are against this (ranking the options which
> allow specifying a dependency on a specific init below further
> discussion), and probably Steve's does too, although I assume that's
> more an objection against the wording.
> 
> At least, the impact seems like it is:
> 
>  - init systems can provide whatever extra APIs they like
>  - other packages can only use extra APIs if they have a dependency on
> the providing package
>  - packages may not depend on specific init systems
> 
>  * therefore packages cannot use the extra APIs

I agree with your conclusion on the practical effect here.

I'm also amused that exactly the same logic readily applies at the next
level down, to an init system making use of APIs and functionality that
Linux has and other systems do not.  In both cases, the question is the
same: least common denominator, or actually using available
functionality?

(To forestall the obvious objection: "optional" is the same as "least
common denominator", in that it effectively prevents *relying* on that
functionality, and thus forces the creation of a
least-common-denominator fallback, which everything higher in the stack
must then cope with.)

- Josh Triplett