Adrian Bunk <[email protected]> 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. 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. L instead requires everyone maintain sysvinit scripts forever, even if they never use them. That (a) significantly reduces the incentive to add the superior native configuration for whatever of systemd, upstart, or OpenRC are not the default, since it's "handled" by the sysvinit script, and (b) makes it much less likely that those configurations will actually be maintained since they're complicated and annoying to try to debug and harder to write "blind" without running them. So I believe L is directly destructive to the stated motives of the people who are in favor of L, which is one of the reasons why it boggles me that it has so much support. 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. But I take extreme exception to your acts of mind-reading, and I ask you to please stop putting opinions in my mouth. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
