Bug#591791: extend init.d policy to permit upstart jobs and describe their use

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Steve Langasek wrote:
> On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:

>> Maybe policy could allow (but discourage) packages that only support
>> some non-Sys-V init system as long as they include a dependency
>> indicating so?
>
> I don't think that's something that should be allowed.  You can only have
> one init system installed at a time

Exactly.  That makes this old suggestion of mine a very bad idea, and
I'm glad you caught it back then, too. ;-)

[...]
>> As a naïve user, I'd prefer the SysV init scripts to pass on requests to
>> upstart when upstart is running; is that feasible?
[...]
> for admin invocations, a frontend
> like the 'service' command is more user-friendly anyway.

I don't agree, but I agree that it's not worth the fuss to teach
/etc/init.d/foo to pass on requests and handle all edge cases
appropriately, so this is academic.

[...]
>> . sysvinit scripts need to behave reasonably regardless of the init
>>   system in use.  So:
>
>>  i. If an equivalent job file for another init system is present, the
>>     sysvinit script will not be automatically invoked by that init
>>     system when switching runlevels.  In this case, when that init
>>     system is in use, the sysvinit script (if invoked by hand, for
>>     example) must either delegate requests to the init system or
>>     error out without doing anything.  Don't fight with init(8).
>
>> ii. Even if an equivalent job file for another init system is
>>     available, the sysvinit script should behave as advertised (and
>>     not be a no-op) when init is sysvinit.
>
> I agree that these are the relevant principles, but I think Policy should
> spell out exact requirements for each init system.

I guess so.  (ii) is already implied by "don't be buggy".  (i) is
probably worth spelling out, though --- I'll look at your patch to see
if it does so.

In an ideal world, (i) would be enough [since it determines the
behavior] and packagers could experiment and refer to each init
system's interface documentation [e.g.  manpages] for details, but I
understand that documenting details on implementation strategy in one
place can be useful for making the result easy to understand.

Thanks again for your work on this!
Jonathan