On 20 January 2014 14:29, Russ Allbery <r...@debian.org> wrote: > Steve Langasek <vor...@debian.org> writes: >> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote: >> For my part I think this is generally a good idea, but I have the >> impression that at least Russ would be strongly opposed to this because >> it's too prescriptive. Probably not much sense in fleshing out such a >> resolution if there's not a consensus for it. > I think this is all great work to do. I'm just dubious about enforcing it > with a technical committee decision. This is the sort of thing that I was > expecting to need to do on the Policy front once we have a decision. I > think that's the right forum for drilling into the details.
So I wondered what it might look like to say the same thing in a minimally prescriptive way. Not even going to try guessing if this is anywhere sufficient as far as Russ is concerned -- I'm not claiming to know where Russ might draw the line on that topic. I've also added some minimal tech ctte-esque boiler plate; I'm sure Ian could do better. --- The tech ctte determines as follows: [non-essential-init] In order to allow Debian users and developers to easily design, test and deploy alternative init systems both now and in the future, no init system in Debian should be provided via an Essential:yes package. [default-init] Having examined the features and bugs of the various init systems packaged for Debian, the default init system for jessie for Linux architectures shall be {OpenRC | systemd | upstart | determined by a GR}. The tech ctte further offers the following advice to maintainers: [logind] The systemd/logind API provided by systemd and documented on the freedesktop API will be important for a number of packages, and that API should be made available within Debian for users of init systems other than systemd. The various non-systemd init system maintainers are encouraged to work with the systemd maintainers and upstream to limit the code duplication that may result from this, and to ensure enhancements and bug fixes are as widely available as practical (both within Debian for different inits/architectures and upstream). The maintainers involved should work through the policy process to establish a virtual package for this API if needed. [required-init] In order to avoid users mistakenly removing all init systems from their machine, we recommend the init maintainers establish a virtual package (eg, "init-system") that all init systems in Debian both provide and conflict with, and that an Essential:yes package depend on that virtual package. This should be undertaken using the normal policy process. [init-minimal-compatability] In order to make it simple for packages to work with different available init systems, a simple means of providing a startup script/configuration that is understood by all Debian init systems should be documented in policy as a requirement for for packages providing the init system virtual package. This may be providing a sysvinit style script and adding it via update-rc.d for instance. This method may be assumed to always be available if the [required-init] advice is followed, and thus packages can avoid a dependency on the virtual package. [init-crossgrades] In order to provide a good user experience when switching init systems, maintainers of init systems other than the default should test converting both to and from their init system, and that the system is able to correctly shutdown and restart after transitions to different init systems. [init-related-patches] Maintainers should accept non-intrusive patches to provide enhanced support for init systems (both for the default init and other inits included in Debian). Patches may be considered intrusive by the maintainer if they introduce additional dependencies or significant patches to code that are not accepted upstream. Patches that merely add files to the package or provide extra code to maintainer scripts should generally not be considered intrusive. Where a reasonable amount of time has been given to the maintainer to review proposed patches via the BTS, and no objection has been raised, a NMU to incorporate the patch is appropriate. [cgroups] Maintainers should be aware cgroups is a Linux-only feature; if their package requires the use of cgroups to be usable it should be configured to not build for non-Linux architectures. Where cgroups support is a compile-time feature, it should generally be supported on Linux architectures, and disabled on non-Linux architectures, for the same reason. [systemd-portability] Maintainers should be aware systemd relies heavily on cgroups and potentially other Linux-only features, and thus should be aware that unless/until this changes, requiring use of a systemd unit file for startup will likewise require their package to be configured to not build for non-Linux architectures. --- I think the [non-essential-init] and any of the four options for [default-init] would 100% satisfy me personally, and I think they're pretty minimally controversial ideas? YMMV. 100% is an approximation. I think given all the discussion, providing some specific /advice/ on how to go forward beyond "hey, X wins!" is a good idea and not too prescriptive. YMMV, again, obviously. The above are the things I think are important and valid issues to address based on the discussion I've seen; and I don't think the advice above would actually be terribly controversial. YMMV on that too, of course. Comparing with Ian's draft in in the tech-ctte git: - non-Linux ports is left up in the air - requiring sysvinit scripts and whether that's an RC bug or not is left as someone-else's-problem as part of [init-minimal-compatability] - depending on a specific init is left to maintainer's discretion; modulo patches/NMUs - providing native support is left up in the air; modulo patches/NMUs - my "reasonable" test for patches is more restrictive -- if upstream don't accept code changes, the maintainer can consider it unreasonable - [7-11] in Ian's proposal seem "prescriptive" to me, so aren't addressed in the above for that reason Again, YMMV, FWIW etc. It seemed an interesting intellectual exercise to make it less prescriptive, and I think the result's somewhat interesting. Feel free to build on it, tear it apart or ignore it as appropriate. :) Cheers, aj -- Anthony Towns <a...@erisian.com.au> -- 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/CAJS_LCWiqUqWUj1NFpRp6=hduym+krrp5zkapvhh0nzzoyw...@mail.gmail.com