On Mon, Feb 14, 2011 at 11:17:20AM +0100, Marco Amadori wrote:
> In data Saturday 12 February 2011 05:55:16, Joachim Breitner ha scritto:
> >> I included some patches to have nodm gracefully uses the upstart job.
> >> Since those patches permits to have both init scripts in the system, no
> >> matter if upstart or sysvinit is used, a little more effort is required
> >> to proper build this package.
> > thanks for your patches. I applied them to the repo besides the patch
> > 0005-Exit-from-the-sysvinit-script-to-use-the-upstart-job.patch. Is that
> > code taken from some existing package?
> I took the idea from discussion on bug #591791 and updated to work also with
> current sysvinit, that does currently not likes the syntax "--version".
> I include again this patch to permits other people to follow the discussion
> there, but is just a matter of :
> if [ -e "/etc/init/${NAME}.conf" ] && /sbin/telinit --version >/dev/null 2>&1
> | grep -qs upstart
> then
> exit 0
> fi
> inside the sysvinit init script.
This does not appear to be consistent with
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791#42, in particular:
If nothing else, an init script that returns success on 'start' without
starting the service would be inconsistent with how we've expected all
init scripts to work to date. (It's not *quite* a policy violation, but
near enough to.) And if you argue that nothing should ever call these init
scripts because everything should use invoke-rc.d, then things using this
upstart-aware interface will never see the return code anyway, right?
Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
grep is always going to return false.
Also, I strongly counsel *against* shipping this, or any, upstart job in a
Debian package until this policy bug is *fixed*. The conversation is
ongoing, and deploying such upstart jobs now realistically just runs the
(very high) risk that you'll have more work to do on your package later once
the policy interfaces are refined and implemented.
BTW, my goal is to provide this functionality in an lsb-style function; that
will preclude both the call to 'exit' here (with any return value) or
checking for ${NAME} in the code; anyway, a package should darn well know
whether it's set up to ship both an upstart job and an init script and not
need to query the filesystem to figure that out.
> Debhelper seems to not permit to have both, e.g., an upstart and a sysvinit
> script available in the package, although with a trick like the above
> mentioned one, the could happily live together in perfect armony, side by
> side
> on my wheezy.
Debhelper doesn't permit both because policy does not specify how this is
supposed to work. I have already submitted a patch to debhelper (bug
#577040), which I have asked Joey to sit on until policy is finalized and
various other key packages have implemented the necessary support (namely,
sysvinit and lsb-base).
Thanks,
--
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
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110214180645.gd17...@virgil.dodds.net
