Bug#727708: init system coupling etc.

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

Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
> > Depending on how this is written, it may depend on the package providing
> > journalctl or it may depend on some shared library that implements the
> > journal reading code, or it might even have no dependencies at all if it
> > implements the journal reading code itself.
> 
> This is not a hypothetical case. It exists, and it uses journald
> directly. The software will not start if systemd is not PID 1.

This is covered by the exception that Colin drafted:

  In general, software may not require a specific init system to be pid
  1, although degraded operation is tolerable.  The exceptions to this
  are as follows:

   * alternative init system implementations
   * special-use packages such as managers for init systems
   * cooperating groups of packages intended for use with specific init
     systems

  provided that these are not themselves required by other software
  whose main purpose is not the operation of a specific init system.

>   Note that
> this is part of what we’d like to put in the gnome metapackage, so
> forbidding this has real impact on real packages for jessie.

What is pulled in by the gnome metapackage is a different issue.  My
draft talks about "software", not "packages", quite deliberately.
There isn't any distinct sofware in the gnome metapackage.  Indeed the
whole purpose of talking about "software" is so that metapackages,
glue packages ("foobar-runit"), and so forth, aren't caught by this
restriction.

Rather, the purpose of a metapackage is to arrange that the right
combination of software is installed.  So I don't think my proposed
wording prevents the gnome metapackage from pulling in systemd in this
way.

Whether the gnome metapackage should pull in systemd like this is
rather a different question.  It is more related to detailed questions
of the desirable behaviour during upgrades etc.  We discussed these in
some detail in the case of gnome -> network-manager.  I don't think we
need to address the metapackage point at this stage although I imagine
the TC may be asked about it.

Ian.