Bastian Blank <wa...@debian.org> writes: > On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
>>> 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). > Automatically is clearly not the same as "file a bug". It is not a > useful way to ask hundreds of people to do things if you can do it on > your own. I think the open question is whether we're happy to just break init scripts in unstable, since that migration path means there will always be a window where a fully-upgraded unstable system has no init script for a package that previously had one and in the future will have one again. This feels like exactly the kind of problem that normally Debian goes to some lengths to avoid creating, but it sounds like several commenters here don't think the effort is worth it? If we don't want to break init scripts in unstable, then the package maintainer should wait for the upload of orphan-sysvinit-scripts that contains the script before uploading the version that drops it. I thought for a bit that some dependency other than Replaces/Conflicts would be appropriate, but the more I think about it, the more I'm not sure there is. (Well, Enhances in orphan-sysvinit-scripts, but I'm not sure that changes apt behavior in any way.) Presumably the sysvinit init system package should depend on orphan-sysvinit-scripts, so the Replaces/Conflicts should then force the right upgrade to happen. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
