Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Ansgar <ansgar@43-1.org>]

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