Bug#727708: multiple init systems - formal resolution proposal
Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:
> > And so I am greatly dismayed by the position Russ and Bdale have taken
> > in this discussion with respect to packages being allowed to depend on a
> > specific init system. Both have expressed the opinion that Debian
> > should remain open to alternative init implementations as long as there
> > are developers willing to do the work; but when it comes to concrete
> > examples of ways in which conflation between init system (that is,
> > service registration and service management) interfaces and dbus service
> > interfaces directly interfere with that goal, they have been unwilling
> > to stand up for the relevant technical principle.
>
> You can be dismayed all you want, but I completely disagree with you about
> the shape of the relevant principle.
>
> There is a huge difference between being open to alternative init
> implementations and requiring that maintainers implement support for
> alternative init systems, which is what the loose coupling option
> requires. The latter is, in my opinion, effectively an attempt to coerce
> maintainers into doing work they don't want to do by holding their
> packages hostage, which is something that I think we should only do for
> things that are absolutely vital to the project. And I don't believe this
> is.
>
> What I want to see is people working with the relevant maintainers,
> understanding their concerns and issues, and find a way to provide
> maintainable support, not just asking the Technical Committee to force
> other people to change how they maintain their packages well in advance of
> actual irresolvable impasses. And when no one has done the work to port a
> particular package to another init system, preventing that current reality
> from being properly represented in dependencies just makes the
> distribution more technically fragile without any real gain for our users.
Well said.
In particular, in the case of GNOME, I don't see any package in the
archive yet for a fork of logind that depends on systemd-shim instead of
systemd, so there's no alternative available for GNOME to depend on.
There's little point to adding a virtual package with no providers yet,
because until the cloud of uncertainty leading to 727708 gets resolved,
a (direct or indirect) dependency on "systemd-sysv | empty-alternative"
seems unlikely to fly, and seems likely to lead to more rants against
the GNOME maintainers for depending on systemd.
It should be completely trivial to introduce a virtual
"org-freedesktop-login1" package (modulo any complexities introduced by
interface versioning for new methods added to that interface). However,
it also seems pointless until there's a prospective provider of that
interface. Do you have a package ready to provide that interface such
that GNOME can depend on it? I've seen no signs that the GNOME
maintainers would refuse to allow alternative providers of those
interfaces once they exist, just refusals to do any work in that
direction until those alternatives *do* exist, which seems entirely
reasonable.
(I'm specifically leaving out the possibility of splitting systemd's
logind out of the systemd package and forcing it to allow alternatives
to a systemd dependency. As effectively demonstrated by the ongoing
work to port logind >> 204 to cgmanager, there is a non-trivial amount
of work required for forks of logind to keep up with the ongoing
development of logind and systemd, and putting that work on the systemd
package will lead to future packaging delays similar to the one
currently blocking a transition past 204. To echo Russ's comments, we
should not hold the systemd packages hostage to force their maintainers
to maintain compatibility with non-systemd. Any such work will
inherently be a fork; better to properly represent it as one and package
it as one, to avoid hampering the unforked version.)
> > This despite the fact that the burden on the GNOME maintainers to
> > support alternate implementations of these dbus services is much lower
> > than the burden of providing sysvinit startup compatibility in jessie
> > for an upstream project that doesn't support it.
>
> The reason why requiring sysvinit startup compatibility makes sense to me
> is because everything in the archive *already* has sysvinit startup
> capability, and therefore what we're asking for is for maintainers to
> sustain the status quo through jessie as much as possible so that we can
> manage an orderly upgrade.
I actually have language written up that would phrase the sysvinit
compatibility requirement for jessie as specifically a requirement to
properly support upgrades from wheezy to jessie, which I think would
make more sense. In particular, that language defined exactly what degree
of "degraded functionality" must be supported under sysvinit: enough to
upgrade from wheezy to jessie, and from sysvinit to not-sysvinit, in
either order, in any environment [including a graphical one].
> I certainly hope that we're not going to have to maintain sysvinit scripts
> indefinitely.
Likewise.
> > As Philipp Kern points out in
> > <41b26b373019ab39ebff223603a085d1@hub.kern.lc>, this leaves us with the
> > very real possibility that we will wind up with mutually incompatible
> > sets of packages in the archive for jessie that are no longer
> > coinstallable, not because the packages themselves have conflicting
> > functionality, but because they've taken sides - intentionally or
> > unintentionally - on the init system question. If we don't think such
> > fragmentation of the Debian archive is an acceptable outcome (and I for
> > one don't see any reason it should be), then we should say as much in
> > our resolution. The committee has a duty to provide strong technical
> > guidance to the project, not just to get involved after something has
> > gone off the rails.
[As an aside, I want to respond to this point: pretty much by
definition, if the technical committee has to consider an issue at all,
something has already gone off the rails. The technical committee is
not a steering committee; it's a mediation process for when normal
collaboration has not succeeded.]
> If you want to explicitly say that packages are required to support the
> default init system, then you should propose language. That's not what
> the loose coupling option says. The loose coupling option says that all
> packages must support *all* init systems, with some possible degredation
> of operation. I believe that effectively locks us into supporting
> sysvinit scripts forever, since no alternative universal common
> denominator seems to be emerging.
Furthermore, I'd argue that the "loose coupling" rider as currently
proposed makes it more *difficult* for alternatives to systemd to
effectively compete with systemd, precisely because of the requirement
to support *all* init systems.
Suppose upstart added compatibility for several of systemd's most
popular daemon interfaces. L, as written, would prohibit daemons from
depending on "either systemd or a sufficiently new version of upstart",
because that makes the daemon depend on specific providers of PID 1.
Thus, as Russ pointed out, "loose coupling" effectively forces the
lowest common denominator of not requiring anything sysvinit lacks.
- Josh Triplett
Reply to: