>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> I think the open question is whether we're happy to just break
Russ> init scripts in unstable, since that migration path means
Russ> there will always be a window where a fully-upgraded unstable
Russ> system has no init script for a package that previously had
Russ> one and in the future will have one again.
Russ> This feels like exactly the kind of problem that normally
Russ> Debian goes to some lengths to avoid creating, but it sounds
Russ> like several commenters here don't think the effort is worth
Russ> it?
Normally, Debian spends a fair bit of effort to avoid these kind of
breakages.
But I think init systems other than systemd are in kind of a special case.
When I go back and look at GR 2019-002, I think the following are true:
* At the time of that GR, only systemd was an officially supported init
system for normal operation. Rationale: GR 2019-002 allows
maintainers to use any systemd facility within some broad constraints
and does not require them to provide an alternative.
* At the time of the GR, services like elogind that supported
* development of alternate init systems *were important to support the
* development of alternate init systems*.
That is, at the time of the GR, when thinking about how important some
* breakage is, we need to consider two cases:
* Does it break the systemd use case? If it breaks things for someone
running systemd then Debian's normal approach to breakage is in
play. I.E. we try to avoid breakage and breakage of upgrades tends
to be a (often RC) bug.
* Does it break things for people doing development of
alternate init systems.
* At the time of GR 2019-002, init systems other than systemd were
only important in so far as they were tools in the process of
developing alternatives to systemd. The use case of someone just
using an init system other than systemd outside of the context of
developing init systems or systemd alternatives was not supported.
My take is that the normal rules about breakage in unstable might well
be relaxed in such a situation. After all the use case we care about is
explicitly the case where someone is actively working on the moving
parts involved.
It also seems a bit strange to require more from the maintainer when
they are dropping an init script than we would if a maintainer started
depending on a feature like socket activation such that their packkage
simply would not work without systemd.
In that case, GR 2019-002 leaves it entirely up to the maintainer
whether they will use that systemd facility and whether they will
support alternatives.
While we're thinking back to 2019, a few other notes:
* At the time of GR 2019-002, init scripts were explicitly supported as a
way to start services.
* The GR explicitly allows us to change the position of the GR without
resorting to a new GR. Processes such as the policy process or a
debian-devel discussion are sufficient. Rationale: it is a statement
of the day, and explicitly has text to that effect at the top.
* So, it is fine that we're effectively removing init scripts as a
first-class option for starting services and saying that the
officially supported option is service units.
* It is possible that the importance of supporting development of
alternate init systems has changed since the time of GR 2019-002. We
are not bound by that GR. For example we could consider what
developments of init system technology have been facilitated since
2019.
* Even if our position has changed since GR 2019-002, I suspect that the text from proposal F still sets a minimum bound on
the support for init systems other than systemd:
> We believe that the
> benefits of supporting multiple init systems do not outweigh the
> costs.
>Debian can continue to provide and explore other init systems, but
>systemd is the only officially supported init system. Wishlist bug
>reports with patches can be submitted, which package maintainers should
>review like other bug reports with patches.
Here's some quotes from GR 2019-002's winning option to justify my
thoughts above.
>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.
Attachment:
signature.asc
Description: PGP signature