Please remove the following email address: e.little...@gmail.com On Sat, Sep 9, 2023 at 10:15 PM Russ Allbery <r...@debian.org> wrote:
> Luca Boccassi <bl...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/> > >
