On 16.03.2012 21:18, Steve Langasek wrote: >> What happens in maintainers scripts that call invoke-rc.d service start? >> Will they now suddenly all fail? How will invoke-rc.d behave when the >> package both installs a upstart job and sysv init script? > > Doesn't this language already cover that? > > Instead, implementations of <prgn>invoke-rc.d</prgn> must detect when > upstart is running and when an upstart job with the same name as an init > script is present, and perform the requested action using the upstart job > instead of the init script.
Seems I missed that, sorry. Yeah, invoke-rc.d forwarding the request to the native implementation looks fine in general. I think it would also make sense to specify, which actions are forwarded. I think policy mandates start/stop/restart/force-reload, status and reload are optional iirc. How would those be mapped to the corresponding upstart (or systemd) jobs. What are we doing about custom actions? Contrary to sysvinit, upstart and systemd don't allow custom actions. E.g. openvpn allows /etc/init.d/openvpn start vpn1 vpn2 ... vpnX Do we specify which actions invoke-rc.d forwards and if so, which ones? 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? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
