Hello, On Wed 17 Oct 2018 at 10:28AM +0100, Simon McVittie wrote: > One part of this section that seems valuable to rescue is: > > If you have an LSB (or "sysvinit") init script /etc/init.d/foo, and > systemd unit(s) that are intended to be used instead of the LSB init > script on systemd-booted systems, then the package must either include > foo.service, or mask foo.service. > > (This is a consequence of how systemd's backwards compatibility for LSB > init scripts is set up. It's a much simpler and easier requirement than > the wording we used to have about how to make Upstart coexist with LSB > init scripts, but it's still a requirement.) Good point. Do the relevant dh_ tools get this right, or might someone packaging a straightforward daemon for the first time get it wrong in their package? If the latter, Policy could discuss it explicitly. On Thu 18 Oct 2018 at 09:57PM -0700, Steve Langasek wrote: > In my mind, the intent of the current policy language is to require an init > script matching any .service units, not for .socket or .timer units. > Perhaps the text should be refined to be systemd-specific instead of > continuing to treat "alternate init systems" generically, and then call this > out? Yes, rewording the text to be in terms of systemd would be a big improvement. At the very least, it would reassure readers that the Policy requirement to include an init script was not just outdated text that did not take into account the changes to init systems that have occurred in recent years. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature