Bug#727708: call for votes on default Linux init system for jessie
On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
> On 28 January 2014 21:39, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> > I don't want to pass a resolution specifying the default without also
> > answering the other two, related, contentious questions:
> > Q1: Do we intend to support multiple systems long-term, or do we
> > intend to settle on a single system, probably in jessie+1 ?
>
> FWIW, that seems overly prescriptive to me -- if we settle on systemd
> now, and as a result upstart stops getting maintained and systemfree
> gets written that uses the same config files but only works on FreeBSD
> and Hurd, maybe no one will want to maintain multiple init systems
> later.
Perhaps a better phrasing would be something like "remain open to
supporting multiple init systems as long as they are actively
maintained".
> Conversely, maybe people get excited about some init system we
> don't pick as default for jessie and it becomes really awesome by the
> time jessie is out; why would we want to prevent it being available in
> Debian even if it's not ready to be default, or doesn't work with
> Gnome yet, or whatever?
(I don't think I can suggest better wording for the "single" options as
they aren't ones I favour.)
> > Q2: Is it OK for packages to depend on a specific init system as
> > pid 1 ?
>
> I don't think that's the right question for the issue(s) at play here.
>
> >From what I can tell, the important question isn't whether systemd or
> upstart happens to be pid 1, but rather whether certain interfaces
> (dbus, logind, potentially others) that are only (currently) provided
> by systemd are available on the system.
That's certainly the principal issue for e.g. GNOME. But I think it's
reasonable to anticipate that some maintainers might want to drop
support in their service packages for init systems which they don't
favour and which aren't the default; one can reasonably take different
views on whether that's appropriate, and I think guidance from the
committee would be useful.
I agree with you that it's worth breaking it down into the matters of
service specifications (which for the most part have resisted attempts
to implement translation layers) and other APIs (which have a better
track record here).
> 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; both systemd and
upstart implement interfaces beyond the bare minimum, though upstart
certainly takes a more minimalist tack.
> After Steve's and Russ's comments in [0] and [1], and thinking about
> it some more, I'm inclined to think all those questions could
> reasonably be dealt with through the policy process, though I still
> think some non-binding advice from the tech ctte wouldn't be out of
> place.
I certainly don't think we should get into the specifics of how things
should be laid out, but the general direction is non-obvious and
important.
--
Colin Watson [cjwatson@debian.org]
Reply to: