[Pkg-sysvinit-devel] startpar support for upstart
kel at otaku42.de
Mon Oct 17 21:55:52 UTC 2011
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.
* 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
More information about the initscripts-ng-devel