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

Re: Last minute cominbations G+D and/or G+E

Ian Jackson writes ("Last minute cominbations G+D and/or G+E"):
> Thanks for this.  No-one else has said anything.  Having thought about
> it, I think Guillem's framing would lead me to a conclusion closer to
> Dmitry's E rather than my option D - but either is arguable.
> To make it concrete I am going to post texts of those two options.  If
> people come forward to say they support or or both of them I will
> formally propose them tomorrow morning (in the hope that the Secretary
> and/or the DPL will allow them on the ballot).  If you support either
> of these options enough, then please formally propose it yourself and
> I will second it tomorrow.
> If no-one else says they are in favour then I will drop this line of
> enquiry entirely (and consequently drop my attempt to force a delay).
> I do not intend either of these proposals to replace E or D, nor G.
> I have been avoiding reading these threads in the evening because it
> is bad for my sleep.  So I won't see whatever followups are posted
> until mid-morning tomorrow UK time.

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.


Title: Support non-systemd systems, without blocking progress


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


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

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

   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 (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).


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

   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).)

Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply to: