[pkg-fso-maint] Bug#602511: Bug#591791: Upstart and sysvinit in packages - Policy needed

[Marco Amadori]

On Monday 14 February 2011 21:07:57 Steve Langasek wrote:

> > 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?

I'm so sorry, in the hurry I put an exit 0 for the wrong psycological reasons, 
you are right.

> Oh, and if you redirect telinit stdout and stderr both to /dev/null, that
> grep is always going to return false.

This is a bad mistake for sure! I apologize to all for being so naïve and 
publishing a bad tested code (I tested an uncommitted previous release, then I 
"improved" and submitted without tests!!)

Again, I apologize.

> Also, I strongly counsel *against* shipping this, or any, upstart job in a
> Debian package until this policy bug is *fixed*.

This seems a good point, having that debhelper prefer upstart jobs over 
sysvinit when both are available.

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

I hope that this discussion could help in clarifing this matter, probably the 
times are mature enough.

-- 
ESC:wq