[Pkg-sysvinit-devel] startpar support for upstart

[Kel Modderman]

Hi Steve,

On Sun, 16 Oct 2011 10:16:01 AM Steve Langasek wrote:
> Hi folks,
> 
> Pursuant to bug #591791 against Debian Policy about permitting alternate
> init systems in Debian, I've prepared a patch against sysvinit which would
> make startpar aware that a given job is implemented as an upstart job
> instead of a SysV init script and that startpar should defer to upstart to
> satisfy the dependency.
> 
> This enables insserv/startpar-based dependency boot to be used for sysvinit
> in conjunction with upstart as /sbin/init and native upstart jobs as
> dependencies, and is the first step towards having upstart be genuinely
> usable on Debian.  It also rolls back the previous /lib/init/upstart-job
> approach, which never worked right with startpar due to the inability to
> express dependency information.  As a result, packages shipping upstart jobs
> should now ship real init scripts in parallel (per the policy bug
> discussion), which means some changes to debhelper are wanted before this
> goes into effect.

Does this mean that the upstart code (to do with /lib/init/upstart-job) in
insserv should be removed alongside this new development?

> 
> It does *not* allow bidirectional dependencies between upstart jobs and init
> scripts.  It's assumed that a system that runs upstart will be converted
> from the bottom up - starting with rcS.d, which more or less needs to be
> converted as a block anyway.
> 
> I've tested this patch to be regression-free on sysvinit as well as working
> with upstart, and verified that the package still builds on non-Linux Debian
> ports after applying (upstart doesn't run there anyway, so it's a simple
> #ifdef :P).  I've also taken care to avoid adding any new runtime library
> dependencies here; it would have been nice to use libdbus for talking to
> upstart, but I guess some might resist such a change. :-)
> 
> Would any of the Debian sysvinit maintainers care to comment on this patch?
> I can't help but notice the 12 consecutive NMUs to the package.  I don't
> mind making this number 13, but would appreciate feedback if there's any to
> be had.

Given the current activity of the maintainers an NMU is the only option.

Comments:
* genarally happy with this approach - it is simple, whereas the
/lib/init/upstart-job concept was somewhat of a blocker trying to
achieve very difficult things that noone in their right mind wants to
throw time at

* not sure the copyright statement of startpar.c should be changed

Thanks, Kel.