Bug#591791: extend init.d policy to permit upstart jobs and describe their use
On Sat, Mar 05, 2011 at 02:19:12AM -0600, Jonathan Nieder wrote:
> 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?
This would be a terrible idea. We would end up with packages that will not
be work together because they depend on different init systems.
> 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.
The whole point of Debian policy is to promote interoperability, not to allow
maintainer to make quick-and dirty packages.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: