On Wed, 04 Dec 2019 at 17:14:38 +0000, Ian Jackson wrote: > Title: Support non-systemd systems, without blocking progress > > PRINCIPLES > > 1. The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > 2. We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > 3. We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight tradeoffs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > 4. Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > 5. This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > > 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 (with no substantial effect on systemd installations) > 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).) Seconded. -- Guilhem.
Attachment:
signature.asc
Description: PGP signature