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

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



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> -8<-
>
> Title: Support non-systemd systems, without blocking progress
>
> PRINCIPLES
>
> 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
>    stack.
>
> 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).)

Seconded. I think this is the 5th necessary second?

Regards,

Matthew

- -- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>

iQIzBAEBCgAdFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAl3oyRUACgkQEvTSHI9q
Y8iPkQ/9EUKmPsbAquCjj1fJroj/aZTWL9i7smpoA4A3KS+pSfWzl9ppfybmuDlz
f8Bgyuv38zFobJsrFZvSHKo75EMdRnwdbXLQYulHmxuD3xO3eY1+Od80uHdmq0Jl
MgSDr0DbiKx27XzZ5LKxJOe+Epr3GTHEF6BCNomHSv6g0HYO4y/2/5n1sonyUjFZ
aTyNa+17NTot7KpWvU6arsFU+QJs/PQLP9O7ZMfP9G7LIYpC/LD8ExLd67udsD4j
BMWd7HlA7ojyeTlATeSOu+S38kCXFX+WPE9dbHDwjW9GEneLVFCTIpK31Sweiz7i
DhxgbEJID75qASwH8VnO495gO0skaGsZq1lOCIh+N7KVJnQ9W9TStSFmfv3sbM/P
bzx98HhQ0AKAXrQGwhtxSMnp3WoIoZnqpQBRNXo8yle11Sprw3f7D6ecgVrn927P
c8jV9If7GDlKOfl+1OOvumkvS8FYrXE25HYyCNd05bAMgRAU45+H8EInv2JnNDiO
xVAVUVPduTkJpeSXn+uExatWnvo7dABWNLHt+ZSBJi9PlrU+ZkD3gOFnXNSOha9V
L+tD4+5+LtQSlKB/9MM0yYdFDQSBAqsjXq9n5foYtKTnqfEOzDP6Up/Q1mnlAKvC
Tx6SWBUCp+x2YFjoDPBGEU8pcrqN6Uod6GTCsWuEu0dQjLHHNco=
=3XS/
-----END PGP SIGNATURE-----


Reply to: