> On 16 Nov 2019, at 18:18, Ian Jackson wrote:
>
> I hereby formally propose the following amendent (for my reference,
> 42471fd). Replace the entire text, with the text below.
>
> -8<-
>
> Title: Support non-systemd systems, without blocking progress
>
> PRINCIPLES
>
> 1. We wish to continue to support multiple init systems for the
> foreseeable future. And we want to improve our systemd support.
> We are disappointed that this has had to involve another GR.
>
> 2. It is primarily for the communities in each software ecosystem to
> maintain and develop their respective software - but with the
> active support of other maintainers and gatekeepers where needed.
>
> SYSTEMD DEPENDENCIES
>
> 3. Ideally, packages should should be fully functional with all init
> systems. This means (for example) that daemons should ship
> traditional init scripts, or use other mechanisms to ensure that
> they are started without systemd. It also means that desktop
> software should be installable, and ideally fully functional,
> without systemd.
>
> 4. So failing to support non-systemd systems, where no such support is
> available, is a bug. But it is *not* a release-critical bug.
> Whether the requirement for systemd is recorded as a formal bug in
> the Debian bug system, when no patches are available, is up to the
> maintainer.
>
> 5. When a package has reduced functionality without systemd, this
> should not generally be documented as a (direct or indirect)
> Depends or Recommends on systemd-sysv. This is because with such
> dependencies, installing such a package can attempt to switch the
> init system, which is not the what the user wanted. For example, a
> daemon with only a systemd unit file script should still be
> installable on a non-systemd system, since it could be started
> manually.
>
> One consequence of this is that on non-systemd systems it may be
> possible to install software which will not work, or not work
> properly, because of an undeclared dependency on systemd. This is
> unfortunate but trying to switch the user's init system is worse.
> We hope that better technical approaches can be developed to
> address this.
>
> 6. We recognise that some maintainers find init scripts a burden and
> we hope that the community is able to find ways to make it easier
> to add support for non-default init systems. Discussions about the
> design of such systems should be friendly and cooperative, and if
> suitable arrangements are developed they should be supported in the
> usual ways within Debian.
>
> CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED
>
> 7. Failing to support non-systemd systems when such support is
> available, or offered in the form of patches (or packages),
> *should* be treated as a release critical bug. For example: init
> scripts *must not* be deleted merely because a systemd unit is
> provided instead; patches which contribute support for other init
> systems should be filed as bugs with severity `serious'.
>
> This is intended to provide a lightweight but effective path to
> ensuring that reasonable support can be provided to Debian users,
> even where the maintainer's priorities lie elsewhere. (Invoking
> the Technical Committee about individual patches is not sensible.)
>
> If the patches are themselves RC-buggy (in the opinion of,
> initially, the maintainer, and ultimately the Release Team) then of
> course the bug report should be downgraded or closed.
>
> 8. Maintainers of systemd components, or other gatekeepers (including
> other maintainers and the release team) sometimes have to evaluate
> technical contributions intended to support non-systemd users. The
> acceptability to users of non-default init systems, of quality
> risks of such contributions, is a matter for the maintainers of
> non-default init systems and the surrounding community. But such
> contributions should not impose nontrivial risks on users of the
> default configuration (systemd with Recommends installed).
>
> NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES
>
> 9. systemd provides a variety of facilities besides daemon startup.
> For example, creating system users or temporary directories.
> Current Debian approaches are often based on debhelper scripts.
>
> In general more declarative approaches are better. Where
> - systemd provides such facility
> - a specification of the facility (or suitable subset) exists
> - the facility is better than the other approaches available
> in Debian, for example by being more declarative
> - it is reasonable to expect developers of non-systemd
> systems including non-Linux systems to implement it
> - including consideration of the amount of work involved
> the facility should be documented in Debian Policy (by textual
> incorporation, not by reference to an external document). The
> transition shoul
