Re: Re-Proposing: General Resolution on Init Systems and systemd
On Sat, Nov 16, 2019 at 11:35:27AM -0500, Sam Hartman wrote:
>
> Choice hartmans1: Affirm Init Diversity
>
> 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 facilities. 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.
>
> 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 and thus may need to be handled differently for each init system. 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; a package having a
> service unit but without an init script is no longer an RC bug, but
> including an init script is appropriate for a non-maintainer upload.
> 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.
Policy editors do no say if a bug is RC or not, they just have
things like MUST.
> 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.
>
> systemd unit files included in the package may use any systemd feature
> or service at the package maintainer's discretion, provided that this
> is consistent with other Policy requirements and the normal
> expectation that packages shouldn't depend on experimental or
> unsupported (in Debian) features of other packages.
Starting from the last paragraph, you seem to be setting policy.
Before that, you just request the policy editors to do something.
But maybe I'm just misinterpreting things.
> Init scripts must use only facilities common to all supported init
> systems in Debian and therefore may not use services that depend on
> systemd.
>
> Similarly, packages may freely use other systemd facilities such as
> timer units, subject to the above constraints, but not also supporting
> non-systemd systems is a (non-RC) bug and non-maintainer uploads to add
> that support are appropriate.
Here you seem to be overriding a delegate by declaring it non-RC.
> systemd facilities may be used at the discretion of package
> maintainers, but modification of Policy to adopt systemd facilities
> instead of existing approaches is discouraged unless an equivalent
> implementation of that facility is available for other init systems.
> ----------------------------------------
>
> Choice hartmans2: systemd but we Support Exploring Alternatives
>
> 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 facilities. 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.
>
> 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 use any systemd facility at the
> package maintainer's discretion, provided that this is consistent with
> other Policy requirements and the normal expectation that packages
> shouldn't depend on experimental or unsupported (in Debian) features
> of other packages. 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.
I don't see how this isn't setting policy.
> 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 hartmans3: Focus on systemd for Init System and Other Facilities
>
> 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 facilities. 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.
>
> 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. Unless the project or relevant parties have agreed
> otherwise, systemd facilities, where they exist and are stable and
> supported by the systemd maintainers, should be preferred over
> Debian-specific ways of solving the same problem unless the Debian
> approach has clear and obvious advantages.
This also seems to be setting policy.
Even though it always says it's using 4.1.5, I have a hard time
seeing why I shouldn't also put them under 4.1.4 (and 4.1.3). As
currently written, I will most likely interprete them as using
the power of 4.1.4, and so require a 2:1 majority.
I didn't have time to properly read all the mails, maybe someone
else mentioned this. If I missed a discussion about this, please
point me to it.
Kurt
Reply to: