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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature