Oh right, should've answered this mail together with the previous, sorry. On Fri, Mar 16, 2012 at 10:46:38PM +0100, Michael Biebl wrote: > > If invoke-rc.d intercepts and redirects the request to upstart (or > > systemd), should update-rc.d do the same? > > Say you run "update-rc.d <service> disable", should this disable only > > the sysv init script, both, or only the upstart/systemd service? > The reason, why I brought this up, is this: > Say you run upstart/systemd and a you have a package which provides a > sysv init script foo, which you have disabled. On upgrades, invoke-rc.d > will respect and not run the service. > In version X, your packages starts shipping a upstart job file. > In this case invoke-rc.d will happily run the upstart job. > Do we require maintainers to preserve the on/off state of the service, > if they start shipping a native upstart/systemd job? What would be the > interface for that? Would this be a one-time migration or done on each > package upgrade? Do we "somehow" ensure the on/off state of the service > is kept consistent between the different init systems, so it doesn't > matter when I switch from sysvinit to upstart (or back again)? I think preserving the on/off state of the service is a good idea, but I also think it's premature to try to specify this in policy; AFAIK there's currently no implementation for either upstart or systemd that does this. There are really two subquestions here: - When a package adds support for other init systems, how does it ensure that the override status for the service is applied to all init systems? - How should an admin disable a service to make sure it's disabled for all init systems? I think the answer to the second is definitely not 'update-rc.d disable'. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature