[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

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.


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

Reply to: