Bug#591791: extend init.d policy to permit upstart jobs and describe their use
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
Reply to: