Hi Michael, Michael Biebl wrote:
> 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 >> fi > > It seems much more sensible to me, to move all this logic into a > separate shell library Would this shell library be four lines? What package provides it? Would it be something that can be used in init scripts shared with other distros (like the above can)? Would it be enough to provide such a shell library and encourage people to use it, or should policy mandate its use to prepare for the shell library to change in some appropriate way in the future? By the way, the above example writes the path to initctl to the terminal when it is present, which I imagine is not intended. [...] > Also, the proposal looks underspecified to me: What happens for other > actions, like stop/restart/reload/force-reload? Yes, I agree. The example should be corrected to prevent the daemon from being started by the restart and force-reload actions. > What happens in maintainers scripts that call invoke-rc.d service start? > Will they now suddenly all fail? According to the proposal, implementations of "invoke-rc.d" 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. > How will "service" behave? Doesn't seem like a matter for policy unless packages need to use "service" directly in some circumstance, but if I remember correctly then upstart overrides the "service" command. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org