Russ Allbery writes ("Bug#727708: init system coupling etc."): > If you do mean that all packages with init system configuration have to > ship sysvinit scripts, I wish the wording would actually say that. This > potentially matters in the long run. For example, consider a hypothetical > future world in which systemd, upstart, and OpenRC are packaged for Debian > and sysvinit has gone away. In that world, I would maintain separate > configuration for systemd, upstart, and OpenRC, since I consider > maintaining those three separate files to be easier than maintaining a > sysvinit script. Is that permitted? If it is permitted, does my package > become instantly buggy when someone packages openlaunchd for Debian?
The draft text in my option says: In general, software may not require a specific init system to be ^^^^^^^^^^^^^^^^^^^^^^ pid 1. The exceptions to this are as follows: I think this leaves open the possibility that software might not work with certain init systems. I'm not trying to say that all software must work properly with all init systems, no matter how experimental or broken. (Although that would be nice of course.) In particular, I don't think this is imposing a requirement for daemons to work with init systems which do not provide at least a compatibility mode for common interfaces (at the moment, the common interfaces for this include sysvinit scripts, inetd.conf and perhaps something else I haven't thought of). In practice what I would like to see is a kind of more powerful compability mechanism that is better able to exploit the better behaviours of more modern daemon supervisors. But at the moment the main compatibility mechanism sysvinit scripts, and all of our init systems support sysvinit scripts. So that means that all packages should ship sysvinit scripts. Work is ongoing on other kinds of compatibility approaches. (It's not even necessary for all daemon packages or all init systems to use the same compatibility approach.) I'm relaxed about the idea of packages having to ship sysvinit scripts indefinitely. Shipping sysvinit scripts does not mean that they have to be handwritten. It would be perfectly feasible for a daemon which only supported a sensible non-forking startup approach to provide an init script which is autogenerated from some kind of meta information (and to use a helper tool for daemonisation). I think there's a clear segment of opinion in the project and amongst our users who want to keep the traditional sysvinit approach. It's not clear whether a minority or a majority will actually want to run sysvinit indefinitely, but even if we think other approaches are better that doesn't mean we should be forcing them on everyone. > I think what you're trying to say, from the above, is: > > All software that needs init system configuration must include > sysvinit scripts. Software may not require any functionality from the > init system that cannot be provided via init scripts, although > degraded operation is tolerable. The exceptions to this are as > follows: > > Also, I assume that this language intends to say that this is forever. In > other words, no package is ever permitted to drop sysvinit scripts, > regardless of what init systems are in use in Debian, at least until the > TC issues another ruling. > > If L passed, that's what I'd assume I was supposed to put in Policy. If > that's *not* what you mean, well, I think it's even more important to > clarify this somehow. For now, yes, you should put that into policy. If we later come up with a better compatibility approach, policy can be amended. The TC decision is defining the objectives, not the details. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21254.1984.23537.903...@chiark.greenend.org.uk