Michael Biebl <bi...@debian.org> writes:
> 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
This seems like a reasonable idea. Steve, what do you think of having
upstart provide such a shell library? Then init scripts could contain
code along the lines of:
if [ -r /lib/init/upstart.sh ] ; then
. /lib/init/upstart.sh
ignore_if_upstart
fi
If upstart and systemd can agree on the same invocation semantics for the
shell library, we could even provide a shell library that handled both and
make this more generic.
> Also, the proposal looks underspecified to me: What happens for other
> actions, like stop/restart/reload/force-reload?
My understanding is that calling those actions directly via the init
script is not necessarily supported and invoke-rc.d should be used
instead. That should probably be spelled out explicitly.
> 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?
Steve's patch requires that invoke-rc.d do the right thing:
+ <p>
+ Because packages shipping upstart jobs may be installed on
+ systems that are not using upstart, maintainer scripts must
+ still use the common <prgn>update-rc.d</prgn> and
+ <prgn>invoke-rc.d</prgn> interfaces for configuring runlevels
+ and for starting and stopping services. These maintainer
+ scripts must not call the upstart <prgn>start</prgn>,
+ <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn>
+ interfaces directly. 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.
+ </p>
> How will "service" behave?
service already handles upstart directly. It presumably could and should
be extended in an equivalent way to handle systemd. I don't think that
needs to be spelled out in Policy, since service is not an interface that
(at least at the moment) is standardized in Policy.
--
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
