Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
> 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.
I do think it's bizarre that we seem to have ended up with coupling
options that don't treat the default init system differently. This
makes no sense to me, for *either* T or L. Unfortunately I was severely
backlogged at the point when this was being thrashed out, and I'm not
confident that I follow the reasoning that led to them being drafted in
a way that's entirely agnostic of the default, which is why I haven't
proposed anything else.
My reasoning about the probable effects of L is much more based on
jessie than the long run. Given that, I don't agree with your reasoning
because I think the injunction to avoid tying higher-level packages to a
specific init system carries more force than the effects of sysvinit
inertia possibly outweighing the activity levels of the various init
system communities; there's still plenty of motivation for those
communities to flesh out native support. For jessie, I'm not sure I see
any practical difference between L as currently drafted and your
suggestion of "required to support default init system, strongly
encouraged to merge support for other active ones"; these seem likely to
be identical in practice for jessie with sysvinit support still around.
In the long run, I can see your point; but (a) I don't think we should
be attempting to rule on the long run now anyway (see below) and (b)
it's not as if we can't develop new policies to suit changed
circumstances.
Part of my concern with T is that it's so mealy-mouthed. "Where
feasible", "should", "encouraged", etc. By contrast, L is a bit
heavy-handed. It sounds like we may share some common goals between
these, and maybe if we want those to stick properly we need to state
those more explicitly rather than using proxies. Do we agree, for
instance, that we want it to be possible to run Debian's major desktop
environments with any of the init systems with communities active in
developing support for them?
Your comments about the package dependency structure make sense to me in
the long term. Where I'm going with my support for L is something like
the zero-one-infinity rule: if a non-init-system package only supports
one system (natively or otherwise, and excluding obvious hacks like
packaging a -dev version of the same system), that may well indicate a
degree of inflexibility, whereas a package that supports more than one
is probably not hard to extend to others.
> 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.
Agreed on both counts. I understand why Ian (was it?) wanted to have
the "multiple init systems for the foreseeable future" text, as a
statement of general intent, and I don't disagree with that. But I
would prefer if the specifics ("Therefore, for jessie and later
releases:") were marked simply as "Therefore, for jessie:". That seems
to dispose of part of your objection to L.
I get that people want to dispose of this so we never have to consider
it again, and that we want to provide more certainty of direction; but I
honestly don't think we should be trying to do that. As people have
been saying in other contexts, the probability space collapses quite a
bit following this decision; with a year of subsequent development the
proper long-term approach will be much clearer.
--
Colin Watson [cjwatson@debian.org]
Reply to: