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

[draft] Draft text on Init Systems GR



This is a draft GR.  I hope to be at a point where I could formally
propose a GR in a week, assuming discussion converges that fast.

At this point, the question is whether the choices that need to be on
the ballot are represented in this draft GR.

I did not obtain a review of this version from someone who favors init
diversity.  I didn't give them a lot of time, and they just wrote to let
me know that they weren't going to be able to do a review this week.
Based on the feedback from debian-devel I decided that getting text to
the community now was the most important thing.
If this text doesn't meet the needs of that community, we'll change the
text.  I hope my actions demonstrate that I've tried to work with and
understand the needs of all sides here; that has been my intent.


----------------------------------------
version 2330c05afa4

Using its power under Constitution section 4.1 (5), the project issues
the following statement describing our current position on Init
systems, Init system diversity, and the use of systemd features.  This
statement describes the position of the project at the time it is
adopted.  That position may evolve as time passes without the need to
resort to future general resolutions.  The GR process remains
available if the project needs a decision and cannot come to a
consensus.

Choice 1: Affirm Init Diversity

Being able to run Debian systems with init systems other than systemd
continues to be something that the project values.  With one
exception, the Debian Project affirms the current policy on init
scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
should include init scripts to start services that are included.
Policy notes that early boot services like those started from
/etc/rcS.d may be tied closely to the init system in use.  Init
scripts are the lowest common denominator across all init systems.
Packages may include support for init systems like systemd service
units in addition to init scripts.  Current policy makes it an RC bug
to include a service unit without an init script.

Policy editors are requested to amend policy; including a service unit
without an init script is appropriate for a non-maintainer upload but
should no longer be an RC bug.  Policy editors are requested to
consider whether there are cases where removing an init script that
used to be provided should be RC because it would break a system on
upgrade.

Once the community of users of an alternate init system have said that
a solution is sufficiently functional for them, others should not
generally second guess this determination.


Choice 2: systemd but we Support Exploring Alternatives


The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features.  Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work.  Technologies such as elogind that facilitate exploring
alternatives while running software that depends on some systemd
interfaces remain important to Debian.  It is important that the
project support the efforts of developers working on such technologies
where there is overlap between these technologies and the rest of the
project, for example by reviewing patches and participating in
discussions in a timely manner.


Packages should include service units or init scripts to start daemons
  and services.  Packages may include support for alternate init
  systems besides systemd and may include alternatives for any
  systemd-specific interfaces they use.  Maintainers use their normal
  procedures for deciding which patches to include.


Debian is committed to working with derivatives that make different
choices about init systems.  As with all our interactions with
downstreams, the relevant maintainers will work with the downstreams to
figure out which changes it makes sense to fold into Debian and which
changes remain purely in the derivative.


Choice 3: systemd  without Diversity as a Priority

The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
Packages should include service units or init scripts to start daemons
and services.


Providing support for multiple init systems or for alternatives to
other interfaces provided by systemd is not a project priority at this
time.

Debian is committed to working with derivatives that make different
choices about init systems.  As with all our interactions with
downstreams, the relevant maintainers will work with the downstreams to
figure out which changes it makes sense to fold into Debian and which
changes remain purely in the derivative.

Packages may include support for alternate init systems besides
systemd.  Maintainers use their normal procedures for deciding which
patches to include.

Attachment: signature.asc
Description: PGP signature


Reply to: