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 package. 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