Bug#727708: multiple init systems - formal resolution proposal
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.
> 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 certainly hope that we're not going to have to maintain sysvinit scripts
indefinitely.
> 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.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: