On Wed, 4 Dec 2019 17:14:38 +0000
Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Ian Jackson writes ("Last minute cominbations G+D and/or G+E"):
> [...]
>
> Here is what I think Guillem's plus mine looks like.
>
> NB that I may have reintroduced typos which have been fixed on the
> website version. I haven't had time to check that.
>
> -8<-
>
> 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.
--
Michael Lustfield
Attachment:
pgpoiNvPXMkBz.pgp
Description: OpenPGP digital signature