Re: Re-Proposing: General Resolution on Init Systems and systemd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sam Hartman writes ("Re-Proposing: General Resolution on Init Systems and systemd"):
> The line of dashes separates each choice.
> I formally propose these general resolution options.
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
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<-
-----BEGIN PGP SIGNATURE-----
iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAl3QPWEgHGlqYWNrc29u
QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTlKIAf+NPsxNaY8WuuG
qSG9sFWNWqt3WcbynfF0Kn0nDcrfqXBSAqIBmJJCwSDXEBUQn+9yahxd2oEmANHg
ToGPqvP0TS8JF53gi4thxzTdJdTV9vDXydRNnre1KYl68/TyrGvKvGXJGfPZ/K7C
K6o+kK5GNAk0nP96ajQiXxUQ+MYQiwAGVM9gCMxFOgHA8Rz/cwKcdZWJgwObAJDD
8IOcsawwgqisoWD5JX5BxB8hVZ1xQTVbrR3Z8Tu7ZlI0yiO5Q2D2HLNEzLZJ3yTN
+kpNeyijYwuHdBJ0V6VFvCdcpUt4/kHsls0esLtUECgzzyY3hE5gD7JICyk5cY8L
D1Ookd6anA==
=9jUR
-----END PGP SIGNATURE-----
--
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: