On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote: > Choice hartmans1: Affirm Init Diversity [...] > Init scripts are the lowest common denominator across all init > systems.
I think naming options "Init diversity" isn't really expressive: if current options "A" and "E" are called "Affirm Init Diversity" or "Init Diversity", does that mean "Option D" is against "Init Diversity"? I've got no better idea, but there should be a bit more to distinguish the proposals. > Choice hartmans3: Focus on systemd for Init System and Other > Facilities > > The Debian project recognizes that systemd service units are the > preferred configuration for describing how to start a daemon/service. > Packages should include service units or init scripts to start > daemons > and services. > Unless the project or relevant parties have agreed > otherwise, systemd facilities, where they exist and are stable and > supported by the systemd maintainers, should be preferred over > Debian-specific ways of solving the same problem unless the Debian > approach has clear and obvious advantages. I don't think this is really what we might want: when there are multiple competing options, Debian-specific or not, developed under the systemd umbrella or not, which on Debian packagers decide to use should only be on merit, i.e. there shouldn't be an implicit "we choose systemd by default". Aspects like "Debian-specific" or "already adopted by other distributions" are fair points for comparison, but whether a given program is developed under the umbrella of systemd or not doesn't really matter. I believe we are mostly thinking of systemd-tmpfiles or -sysusers here which do have a "Debian-specific (and currently imperative)" and "systemd-provided" implementation, but as a slightly different example consider resolved / unbound: here one is systemd-provided, but the other non-Debian-specific. But there is no inherit advantage of "resolved" over "unbound" just because it is developed as part of systemd. What does matter to me is that we don't block the idea to use facilities like systemd-tmpfiles or -sysusers on Linux just on grounds of them being developed under the umbrella of the systemd project, and that we don't create barriers that don't exist for other developments such as arbitrary requirements for Policy inclusion just on grounds of something developed in a specific upstream Git repository when these barriers don't exist for comparable facilities provided by a different upstream project (as Option D would introduce). This affects both this paragraph and the name of the option. So a try to better reflect that idea: ``` Choice 3: Affirm systemd as preferred init system; allow tooling evolution The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. Packages should include service units or init scripts to start daemons and services. [No change here.] The project commits to open evolution of tooling in the future. This explicitly includes the possible adoption of facilities provided under the systemd project umbrella such as systemd-tmpfiles or systemd-sysusers if such facilities are considered useful and the preferred available implementation. The project recognizes this might create additional work for, for example, non-Linux ports, but believes this alone should not be considered a blocker for adoption. [Following paragraphs as before] ``` > Providing support for multiple init systems or for alternatives to > other interfaces provided by systemd is not a project priority at > this time. Besides non-Linux ports I don't see why one would want an alternative for programs like the ones mentioned above? In addition this seems to overlap with the last paragraph below, but here we talk about "alternatives to other interfaces" and below not. So maybe just have the last paragraph and merge the "alternatives" in there? But I have only a very weak opinion on this. > Debian is committed to working with derivatives that make different > choices about init systems. As with all our interactions with > downstreams, the relevant maintainers will work with the downstreams > to > figure out which changes it makes sense to fold into Debian and which > changes remain purely in the derivative. > > Packages may include support for alternate init systems besides > systemd. Maintainers use their normal procedures for deciding which > patches to include. ``` Packages may include support for alternate init systems and/or other facilities as mentioned above besides systemd. Maintainers use their normal procedures for deciding which patches to include. ``` Ansgar
