Hi Laszlo, On Tue, May 24, 2011 at 07:08:22PM +0300, Laszlo Papp wrote: > I have tried to use the debian/rules that you can see below. My > concern is that I would like to make a test package (for maemo, but > actually should also work for debian) in case of using upstart for > init functionalities. > The problem is that if I try to use a debian/cups.upstart file for > that purpose, it seems to be hard coded. It installs the upstart job > into the /etc/init/ and I cannot customize that path, for instance to > /etc/init/apps/ as I would like to have it. I tried to set the > "--onlyscripts" option in order to hope that it does not generate any > init script/job inside the package and I could just make a workaround > by using postinst.
It installs it to /etc/init because this is the upstream path for upstart
jobs. There is no dh_installinit implementation that knows about this
maemo-specific /etc/init/apps/ path.
You could patch dh_installinit to do this in a maemo context, or you could
pass DEB_DH_INSTALLINIT_ARGS=--name=nonexistent to force dh_installinit to
only look for debian/cups.nonexistent.upstart.
> Other option is to change the whole packaging to "dh" usage. However
> if I could just bypass the systemv init script and/or hard coded
> upstart job installation, it would be easier for me because I am not a
> packager. =)
With dh the solution is certainly more easily discoverable and less
convoluted; you can override dh_installinit with a simple rule:
override_dh_installinit:
$stuff_to_manually_install_to_etc_init_apps
--
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/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
