Ansgar <ans...@43-1.org> writes: >>> 9.11 states: >>> >>> +--- >>> > Alternative init implementations must support running SysV init >>> > scripts as described at System run levels and init.d scripts for >>> > compatibility. >>> +---
> Thinking a bit more about this, I think this requirement should just be > removed from Policy. It should be left to the individual communities > interested in a particular init system how much compatibility with > sysvinit is useful for them. I think the current approach in the entirety of 9.11 no longer makes sense, but there are two possible alternative approaches and which to pick will depend on the results of the current GR. Therefore, I think we should for the results of the GR rather than doing work on this right now. The two alternatives I see are: 1. Some GR option saying that systemd is the only supported init system wins. In that case, we're going to be deprecating init scripts since the integration proporties of unit files are so much better, so we'll be making other changes to Policy to document systemd units as the preferred syntax for configuring services and everything 9.11 currently says should be deleted. (We probably still want a section on alternative init systems, but it would be much different.) 2. Some GR option saying that we want to continue to maintain init scripts for compatibility with other init systems wins. In this case, I think we should document the common init script syntax used for compatibility purposes along with whatever rules the GR indicates we should have for when an init script alongside a systemd unit is required. Then, I think we should rephrase 9.11 to instead say that services are configured with either unit files or init scripts and an alternative init system therefore would need to handle one or the other or it won't be able to properly boot Debian. (Which does not necessarily mean that it would violate Policy requirements; there's nothing wrong with packaging init systems intended for use inside containers or other special-purpose environments that do not need to support arbitrary Debian packages. But any alternate init system should make clear which of those use cases it's aiming at.) -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
