Wednesday 12 June 2013

Re: Boot-related updates in raring: forwarding upstart support to Debian

On Wed, Jun 12, 2013 at 04:58:00PM +0100, Dmitrijs Ledkovs wrote:
> On 19 May 2013 02:14, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> > Before forwarding upstart jobs, there are a few things to be aware of. The
> > tl;dr version of this for those who just want to start fixing packages and
> > forwarding patches can be found at
> > <https://wiki.ubuntu.com/UpstartCompatibleInitScripts>.

> I've converted a non-trivial scripts into upstart compatible scripts.
> And I have a question about exact requirements behind:

> "Make sure that the upstart jobs and init scripts in the package have
> matching names. If the names do not match, either the init script
> should be split (cf. /etc/init.d/samba->/etc/init.d{s,n}mbd in the
> samba package), or dummy upstart jobs should be created (cf.
> /etc/init/mountall.sh.conf in the mountall package) so that the names
> line up. Without this, insserv will not correctly detect that the
> upstart job has started and dependency-based booting will fail."

> What are the exact requirements here? one-to-one matching?
> For example in util-linux package there are:
> - in debian: hwclock.sh init script
> - in ubuntu: hwclock and hwclock-save upstart jobs

So the precise requirements for insserv compatibility are that if a SysV
init script should be skipped in favor of an upstart job when running under
upstart, there must be an upstart job with the exact same name as the init
script to be skipped.

Combined with the requirement in Policy 9.11 that packages *must* continue
to support SysV init in Debian and not be upstart-only, this means in
practice that almost all packages should have a 1:1 mapping between sysvinit
scripts and upstart jobs.

However, one key exception are packages that implement the init system
itself. As policy puts it:

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 `/etc/rcS.d/' scripts and may
not have a one-to-one correspondence with the init scripts.

hwclock isn't part of an init system per se, but the hwclock.sh script *is*
shipped in /etc/rcS.d. So it's not surprising that these don't end up being
1:1.

> I have added the two upstart jobs and created an "dummy" hwclock.sh
> upstat job with "start on started hwclock" condition, thus to hint
> insserv that upstart can handle starting "hwclock.sh" correctly.

Yep - that sounds exactly like what I did in the mountall package.

> Do I still have to introduce hwclock & hwclock-save init.d scripts as
> well? Or does one only need such compat scripts if there are other
> sysv init scripts that declare dependency on "hwclock.sh"?

You don't need them, at all. Any init scripts that *do* declare a
dependency on 'hwclock.sh' will have this dependency satisfied by the
hwclock.sh upstart job.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org