Luca Boccassi <bluca@debian.org> writes:
> systemd upstream will drop support for the transitional sysv generator
> in the near future. The transition is long finished, it's been at least
> a decade, and it's time for the tail of packages still shipping only
> init scripts but not units to be updated.
> Tentatively this should happen within Trixie's development cycle. Of
> course it's free software and generators are not that difficult to
> maintain, so if someone wanted to lift the sysv generator out of the
> systemd repository and adapt it to be a standalone binary there's
> nothing stopping them. But I wouldn't want the systemd package to depend
> on such a backward compat tool, so packages needing this hyptothetical
> package should depend explicitly on it. This is just mentioned for
> completeness, it's been at least a decade and writing a unit file is
> beyond trivial so there shouldn't be any issue adding the few remaining
> ones.
The mass bug filing happened, and although there were some objections on
debian-devel, I don't think any of them were blocking. Specifically, I
did not see anyone present a concrete plan for how to keep the systemd
unit generator or some equivalent alive, and given that systemd upstream
is dropping support for this feature, I believe that's the only way for
this change to not be effective mandatory.
Therefore, I think the time is ripe to proceed with this Policy change.
I took a detailed look at this part of Policy today, and the whole system
service section needs serious work. I believe the instructions it
currently provides for constructing package maintainer scripts won't
actually work with a current Debian system, and most Debian packages are
technically violating the current Policy because it hasn't been updated
for how systemd units work today. I started on overhauling that section,
but it became clear that this is going to be a larger project with some
potentially controversial decisions, so I'm going to open a new bug about
that so that we don't block this change on that work.
I made the following changes to your last diff:
* Move the "should" about integrating with service management to the
parent section.
* Explicitly say that systemd is the default init system and service
manager (it feels like we should say this somewhere, and I don't think
we already do).
* Add an explicit exception for packages intended only to support
alternate init systems. (As an obvious example, sysvinit isn't going to
ship a systemd unit, nor should it.)
* Delete the paragraph suggesting that packages without systemd units
should write an init script, since this will no longer accomplish the
goal of getting that system service to work with systemd and therefore
no longer seems to serve a purpose.
Here is what I came up with. I think it is ready for seconds or
objections.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>