[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian packages and upstart jobs

On Sat, Dec 12, 2009 at 07:49:58PM +1000, Kel Modderman wrote:
> > One of the packages I maintain, OpenAFS, is a network file system.  As
> > such, one generally wants it to start before things like gdm that need to
> > read the user's home directory.  However, in Ubuntu, gdm is started by
> > upstart instead of an init script, and all init scripts are run after the
> > native upstart jobs are run.

> > The best way to address this for Ubuntu would be to introduce an upstart
> > job for OpenAFS.  However, the package is in universe and hence
> > preferrably shared between Ubuntu and Debian.

> > Is there any reason why it would cause problems for me to add an upstart
> > job to the Debian package, even though Debian doesn't currently use
> > upstart?  (I realize that the logic around deactivating the init script if
> > upstart is present may be a bit complex, but I suspect we can find ways of
> > dealing with that.)  I assume the job just sit there quiescent until
> > Debian switches to upstart.

> debehlper >= 7.4.1 contains an implementation of dh_installinit which takes
> care of debian/$package.upstart (and debian/$package.$name.upstart when called
> with --name= parameter) by installing the job(s) to /etc/init.d/ with a
> symlink from /etc/init.d/$jobfile -> /lib/init/upstart-job. It also adds
> 'upstart-job' to the substvars in misc:Depends.

> The status of 'upstart-job' is unknown to me, which raises my concern that
> Debian boot system may not be ready for upstart jobs when they are installed
> by dh_installinit.

Currently, the only provider of the "upstart-job" virtual package in the
archive is upstart itself.  So if you use dh_installinit to install an
upstart job, your package will force the installation of upstart onto the
system, which is not what we want.

The plan of record is to get an upstart-job implementation in place that
works with sysvinit, so that maintainers can ship *only* an upstart job, no
init script, and have the compatibility layer handle everything on systems
not running upstart (including architectures to which upstart can't be
easily ported).  That compatibility layer, once available, will conflict
with any efforts to ship both an upstart job and an init script in the

So if you really want to upstartify the package for Ubuntu (which isn't
necessary - the current focus in Ubuntu is upstartifying those services that
are on a default system, there's not as much benefit to converting other
services yet), my personal recommendation for now would be to build the
package differently for Debian than for Ubuntu.

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

Attachment: signature.asc
Description: Digital signature

Reply to: