Hi Russ,

On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
> Adrian Bunk <b...@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.

So to make my position clear:  L does not accurately reflect what I think we
should be doing; but given the option between L and T, I was willing to vote
L above FD and was not willing to vote T above FD because I think T
unambiguously sets the stage for all other init systems to wither away in
Debian and I think it's foolish for the TC to say they are "welcome" under
such circumstances.

If option T also dropped the text saying that we "welcome contributions of
support for all init systems", I would vote T above FD - but narrowly,
because I don't think this is a good outcome either.

Here's what I think is the right technical policy, that we should be
addressing with this resolution.

 - Packages in jessie must retain compatibility with sysvinit startup
   interfaces (i.e., init scripts in /etc/init.d).
 - Packages can require other interfaces for their operation that are
   provided by an init system implementation, but which are unrelated to
   service management; however, these requirements must be expressed in a
   way that does not tie them to a single init system package.  E.g., a
   package that uses the logind dbus interfaces is absolutely free to do so,
   but must not express this usage as 'Depends: systemd'.
 - The TC should make no ruling at this time regarding releases beyond
   jessie.

I'm not trying to tell maintainers they can't use native service management
interfaces to systemd or upstart post-jessie, but I do think we need to make
clear what's expected for jessie, if for no other reason than because of the
upgrade requirements (which AIUI you agree with - or did, earlier in the
discussion).  And I don't object at all to packages using logind - logind
itself is a very good thing! - but if we actually intend to be open to
alternative init systems, then maintainers should be expected to do the bare
minimum of work (i.e., declaring dependencies appropriately) required to
leave the door open for this.

Laid out like this, do you see room for a compromise option on the ballot?
Is there any value in me expanding on why I think the second point should be
part of this decision?

> 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.

Multiple init systems are viable today only because we have a common
baseline interface, defined in Policy.  Once we allow packages to drop
support for sysvinit in favor of native systemd units, we no longer have a
least common denominator interface.  Init systems that can't handle systemd
units directly are going to have an insurmountable disadvantage.  This is
not assuming bad faith, only human nature - as soon as sysvinit is not the
default and sysvinit compatibility is no longer a policy requirement,
support for non-systemd init is going to bit-rot in the archive, because
it's no longer a development priority; some maintainers will even stop
shipping init scripts as unsupported/untested, or because they're known
broken and no one has stepped forward to update them.  The shift of
responsibility from individual maintainers to take care of their init
scripts for proper functioning, to some hypothetical community of init
system afficionados, is not a trivial thing.

An init system that can only be used for running specific services that the
init system maintainers have added support for is not technically
interesting.  I don't see how any member of this committee could believe
otherwise.

And ultimately, if there's no path forward that sees multiple init systems
actually supported in Debian, then I think we should be honest about that.
Hedging to say that some stupendously motivated unknown party *could* make
another init system work in Debian without the benefit of a common baseline
just gives people false hope, while distracting from the work of providing
good native support for the init system we're choosing to make the default.
Likewise, leaving it to individual maintainers to decide when to drop
support for sysvinit, instead of providing project-level guidance about when
this can be done, is only going to prolong the dispute, squandering our
maintainers' time and motivation.

> 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.

I suspect that in practice you and I are not actually very far apart in what
we want to see out of a decision, and that we've been talking past each
other for a good part of this.  I hope that with a little more focused
discussion, we can converge on something that has the support of the full
TC.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slanga...@ubuntu.com                                     vor...@debian.org

Attachment: signature.asc
Description: Digital signature

Reply via email to