On 16.03.2012 20:09, Adam D. Barratt wrote: > On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote: >> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote: >>> Oh, yes, I misunderstood that too. How about: >> >>> These maintainer scripts must not call the upstart >>> <prgn>start</prgn>, <prgn>restart</prgn>, <prgn>reload</prgn>, or >>> <prgn>stop</prgn> interfaces directly. >> >>> which uses the same term (interfaces) that is used for calling invoke-rc.d >>> and update-rc.d? >> >> Looks good to me. Attached. > As I've already mentioned before, I don't like the approach, that any init script should use something like: > if [ "$1" = start ] && which initctl && initctl version | grep -q upstart; then > exit 1 > then It seems much more sensible to me, to move all this logic into a separate shell library, and instead of hardcoding the above commands in the sysv init script, policy should just mention that maintainers that wish to provide both an upstart job and sysv init script would source this library in the sysv init script. Otherwise it will lead to copy&paste and maintenance nightmare Also, the proposal looks underspecified to me: What happens for other actions, like stop/restart/reload/force-reload? 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? How will "service" behave? There are too many open questions, so I can't support the text in the current form. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature