Hi,
Steve Langasek wrote:
> Sorry this has taken so long; I spun my wheels on it
> for some time because I couldn't quite accept that there were so few
> additional requirements that needed to be specified here!
Thanks for your work. :)
[...]
> + tasks at boot time. However, any package integrating with other
> + init systems must also be backwards-compatible with
> + <package>sysvinit</package> by providing a SysV-style init script
> + with the same name as and equivalent functionality to any
> + init-specific job, as this is the only start-up configuration
> + method guaranteed to be supported by all init implementations. An
> + exception to this rule is scripts or jobs provided by the init
> + implementation itself; such jobs may be required for an
> + implementation-specific equivalent of the <file>/etc/rcS.d/</file>
> + scripts and may not have a one-to-one correspondence with the init
> + scripts.
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?
One of the advantages of upstart and its kin is the simpler
configuration, after all, so I can imagine some maintainers wanting to
take advantage of that and not having time to debug a standard init
script. The example that led me to mention this is Bug#422139; it is
not quite the same issue but is related.
> + SysV init scripts for which
> + an equivalent upstart job is available must query the output of
> + the command <prgn>telinit --version</prgn> for the string
> + <tt>upstart</tt>
As Tollef mentioned, upstart can be installed without being init.
This currently spews a usage string to stderr on sysvinit. I wonder
if there is some other way to ask init whether it is upstart? 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?
I suspect it would be best to make the language init system neutral,
and to say something to this effect:
. 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.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110305081912.GA24071@elie
