Re: Policy consensus on transition when removing initscripts.
On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote:
> Bastian Blank <waldi@debian.org> writes:
> > Sorry no. Please add a conversion layer that adopts service and
> > maybe other systemd units to initrc if you care about it. This is
> > what systemd does to adopt existing init scripts, so you can do the
> > opposite.
>
> I don't think it's useful to tell people who are working on sysvinit
> support how best to do that work. We decided to not require support
> in packages and put the maintenance burden on the sysvinit
> maintainers. It feels rude to me to do that and then try to second-
> guess how they choose to do that.
I think sysvinit maintainers looked at such ideas in the past, but
weren't capable to get it to work. That might be a blocker for such
approaches. There was also a GSoC project in 2012 and some other work.
> [...] we should respect it.
But not necessarily much more than the community the thread starter
works with shows towards others.
> > And it can detect easily if no init script exists for a given unit,
> > so no coordination necessary.
>
> Replaces and Conflicts are required at the very least so that
> upgrades work properly, and I don't see any reason why we shouldn't
> provide instructions to package maintainers to do that smoothly,
> rather than having the init script disappear and then reappear and
> break users who are using unstable. It's not that difficult to slow
> down a little bit and follow a process.
Neither orphan-sysvinit-scripts now! nor the packages it ships legacy
startup scripts for seem to have Replaces or Conflicts though?
I also don't think we should put anything here on the critical path:
that lead to problems with, for example, systemd-shim which was
promised to get maintained and timely updated...
Less prone to errors than a manual process might be to watch
automatically where legacy startup scripts disappear anyway; it's not
that complicated to do. People tend to forget things.
Ansgar
Reply to: