[2019-11-16 18:18] Ian Jackson <email@example.com> > - -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 should be smooth for all users. The non-systemd > community should be given at least 6 months, preferably at least 12 > months, to develop their implementation. (The same goes for any > future enhancements.) > > If policy consensus cannot be reached on such a facility, the > Technical Committee should decide based on the project's wishes as > expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 10. In general, maintainers of competing software, including > maintainers of the various competing init systems, should be > accomodating to each others' needs. This includes the needs and > convenience of users of reasonable non-default configurations. > > 11. Negative general comments about software and their communities, > including both about systemd itself and about non-systemd init > systems, are strongly discouraged. Neither messages expressing > general dislike of systemd, nor predictions of the demise of > non-systemd systems, are appropriate for Debian communication fora; > likewise references to bugs which are not relevant to the topic at > hand. > > Communications on Debian fora on these matters should all be > encouraging and pleasant, even when discussing technical problems. > We ask that communication fora owners strictly enforce this. > > 12. We respectfully ask all Debian contributors including maintainers, > Policy Editors, the Release Team, the Technical Committee, and the > Project Leader, to pursue these goals and principles in their work, > and embed them into documents etc. as appropriate. > (This resolution is a position statement under s4.1(5).) > > - -8<- Seconded. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Description: PGP signature