Hi,
On 2019/11/19 02:37, Sean Whitton wrote:
> 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:
>
I too, continue to second Ian's proposal with the following 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<-
>
Attachment:
signature.asc
Description: OpenPGP digital signature