Bug#727708: Call for votes on init system resolution
Adrian Bunk <bunk@stusta.de> writes:
> Leaving tactical aspects aside, IMHO the important point is that there
> is a compromise line that seems reasonable for all members of the TC:
> For the upstart side of the TC, the most important question is T/L.
> For the systemd side of the TC, the most important question is D/U.
I don't agree with this analysis.
I consider the L option as currently written to be a commitment to a
course of action that is technically broken and unsustainable. I also
think the effect of L is contrary to its intended goal and will make it
less likely, not more likely, that Debian will provide working support for
any init system other than the default in the long run. (More on that
below.)
L is only "less important" to me because I believe it is unworkable and
unimplementable in the long run, so it doesn't matter *that* much if it
wins, since it will naturally get dropped over time. Eventually, package
maintainers will realize that the sysvinit scripts everyone has been
keeping around to give lip service to L don't actually work and aren't
actually maintained, and it will end up like other similar Debian features
that are "required" but uninteresting to nearly everyone and therefore
bitrot and are effectively non-functional.
L will cause less short-term damage with systemd as the default init than
with upstart or OpenRC as the default init, so I'm grudgingly willing to
vote DL above FD because the results wouldn't be quite as absurd as the
results of UL would be, but I'm quite far from happy with it. In
practice, I expect any of the L options to require another round of this
discussion post-jessie to get rid of L again so that we can move forward
without keeping sysvinit scripts. I certainly hope they will, since the
alternative is to have a decision on the books that maintainers are
supposed to comply with but, in practice, won't, which is an embarassing
and annoying situation to be in.
L makes it less likely that Debian will support anything other than the
default init system in the long run because it undermines the process of
adding native configuration for non-default init systems. If we said that
packages are required to support the default init system and strongly
encouraged to merge support for those with active communities, I think we
still wouldn't get 100% archive coverage for the non-default, but I do
think we'd get coverage for most or all of the packages that people using
the non-default init system care the most about. That would probably be
in the form of native configurations for the init systems that people care
about, since all the native configurations are simpler and easier to
maintain than sysvinit scripts. Packages would then depend on the set of
init systems that they support. I think that's about the best solution we
can hope for in the long run: strong support for the default init system,
and workable but incomplete support for the other init systems, with clear
indication in the package dependency structure of what init systems are
supported.
L instead requires everyone maintain sysvinit scripts forever, even if
they never use them. That (a) significantly reduces the incentive to add
the superior native configuration for whatever of systemd, upstart, or
OpenRC are not the default, since it's "handled" by the sysvinit script,
and (b) makes it much less likely that those configurations will actually
be maintained since they're complicated and annoying to try to debug and
harder to write "blind" without running them. So I believe L is directly
destructive to the stated motives of the people who are in favor of L,
which is one of the reasons why it boggles me that it has so much support.
My preference would be to vote on Bdale's ballot, and I'm unhappy that we
didn't just continue with that vote. However, I'm almost entirely out of
spoons to keep arguing wording and procedural issues, and I think we're at
the point where this process is starting to cause active damage by
continuing to drag on. But apparently I'm failing to keep my mouth shut,
so, well, here you go.
Neither T nor L actually imply what I think will happen in practice. The
T option gives explicit blessing to adding dependencies on non-default
init systems, which I think is something that's only appropriate on a
case-by-case basis for edge packages and cooperating package groups and
isn't appropriate general advice. It also doesn't distinguish between
right now and after the jessie release, which I think is inappropriate. I
think there's a huge difference between depending on an init system right
now for the jessie release, which is something I think we should only do
if there's really no technical alternative available at all, and depending
on an init system or set of init systems after jessie, which I think is a
reasonable way of handling the long-term migration path away from
supporting sysvinit scripts.
I tried to raise these issues multiple times and was roundly ignored, so I
gave up and just voted the best order I could come up with that I think
will result in sensible things happening in the long run, even if some of
the options are not particularly sensible. But I take extreme exception
to your acts of mind-reading, and I ask you to please stop putting
opinions in my mouth.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: