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

Re: [draft] Draft text on Init Systems GR

Hello all,

Sam Hartman [2019-11-07 13:04 -0500]:
> 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.

Many thanks! (Again, in public now :-) )

Full disclosure: I discussed that with Sam in private before, as representative
of the systemd maintainers.

> 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).

To clarify: Is the exception to alter the "must" in the current policy, that

   However, any package integrating with other init systems must also be
   backwards-compatible with sysvinit by providing a SysV-style init script


> Roughly, packages should include init scripts to start services that are
> included.

I. e. changing "must" to "should", and thus stop making packages like
cockpit have an RC bug. cockpit has deep systemd dependencies both for startup
and at runtime -- support for non-systemd will not happen. So even choice 1
would mean to move from "everything in Debian must work with SysVinit" to "we
accept that there are some packages in the archive which only work with

This may soon apply to GNOME as well:

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

This is ambiguous: I think you mean that "a package having a service unit but
without an init script is no longer an RC bug", not that the process of
*including* a service unit is an RC bug. So how about

   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


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

+1 that makes absolute sense for Choice 1.



Attachment: signature.asc
Description: PGP signature

Reply to: