Bug#727708: Call for votes on init system resolution
Colin Watson <cjwatson@debian.org> writes:
> 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.
It's been a really long thread, and I think we're all running low on
spoons. It's clear that I should have pushed a bit harder on some points
that Ian indicated continued disagreement with rather than assuming his
disagreement was echoed by you, Steve, and Andi.
> 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.
Oh, yes, absolutely. I agree with most of L for jessie as long as we
carve out a few reasonable exceptions. I think I proposed limiting L to
jessie somewhere in the thread, Ian disagreed, and I dropped it. I'd be
very happy to resurrect something akin to that.
> 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?
Yes.
I don't think the GNOME maintainers, to take a concrete example, should be
required to make that support appear if it doesn't exist. But so long as
someone provides a logind-compatible service that doesn't require systemd,
it certainly seems reasonable to me to advise the GNOME maintainers to
allow it to satisfy the dependencies of GNOME. My impression is that none
of the GNOME maintainers object to this idea, only to the assumption that
such a service will necessarily materialize and that it's therefore
reasonable to flatly require they not depend on systemd. If things go as
both you and Steve expect them to go, this whole problem simply
disappears, and is replaced with some technical work about how best to
represent the dependency structure, source packages, and so forth, which
I'm confident can be resolved amicably by all parties.
> 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.
I think one of the problems that we ran into was that we ended up
entangling what init system configuration the package ships with and the
whole logind issue, and they're really somewhat separate issues with
different long-term dynamics.
> 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.
I completely agree with this. I think there's some reasonable chance
that, a year or two from now, things will have sorted out sufficiently
that we can reach a normal project consensus on where to go next.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: