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

Re: [draft] Draft text on Init Systems GR


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

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

Reply to: