[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-Proposing: General Resolution on Init Systems and systemd

> On 16 Nov 2019, at 18:18, Ian Jackson <ijackson@chiark.greenend.org.uk> 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
> 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.
> 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.
> 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).
> 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.
> 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 (with and without my kFreeBSD hat).


Reply to: