Bug#591791: Upstart and sysvinit in packages - Policy needed
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
Reply to: