Hello,
On Mon 18 Nov 2019 at 04:57PM +00, Ian Jackson wrote:
> Russ Allbery writes ("Re: [draft] Draft text on Init Systems GR"):
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> > + (with no substantial effect on systemd installations)
>>
>> Yes, that looks great to me.
>
> I have folded it in and the result is below.
>
>> Let me know if it would be helpful for me to propose it. Happy to do so.
>> I was also unclear on who can accept amendments to unaccepted amendments.
>
> Please do formally propose it and I will give my formal blessing to
> it.
If needed: my seconding of Ian's proposal continues to apply to the
following revised quoted amendment:
> -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 (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).)
>
> -8<-
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature