Steve Langasek <vor...@debian.org> writes: > Packages are shipping systemd units in the archive today, and Policy > *should* cover this case. Currently, it covers this by saying "you can > integrate with systemd, but must still provide compatibility with > sysvinit", which I think is fine at this stage.
I think it's worth noting that the Policy documentation for both upstart and systemd is minimal at this point. The only reason why there's any upstart documentation at all is that the upstart maintainers took the approach of requiring init scripts to disable themselves when upstart is running (requiring a Policy mention), whereas the systemd maintainers took the approach of ignoring init scripts that have the same name as systemd units and implementing all the required update-rc.d and invoke-rc.d glue to keep state in sync. (I have a mild preference for the systemd approach over the upstart approach here, but I don't think it's a significant difference.) In *both* cases, substantially more Policy documentation will be required if we adopt that init system, particularly around upgrade cases from sysvinit scripts and some of the edge cases such as /etc/default settings to disable starting a service. I ran into several things with both upstart and systemd that would need Policy documentation to ensure that we did them consistently. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org