Colin Watson <cjwat...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
