On Monday, June 26, 2023 12:45:11 PM EDT Ansgar wrote: > 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. That sounds reasonable. It might be sufficient for the policy discussion to say that maintainers who drop sysv init scripts should file a bug against orphan- sysvinit-scripts with the final version of the provided init attached and which lists the lowest version that won't include it (so that orphan-sysvinit- scripts can Replaces << that version). Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.