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. _______________________________________________ initscripts-ng-devel mailing list initscripts-ng-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/initscripts-ng-devel
