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
signature.asc
Description: Digital signature
