On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote: > Bastian Blank <wa...@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
