[Pkg-sysvinit-devel] Bug#768138: uwsgi: Enhancement to uwsgi-emperor.init.d

[Petter Reinholdtsen]

[Jonas Smedegaard]
> Thanks for your suggestion.  It does look like a harmless change, but I 
> am not fully certain, and have also now switched to use the 
> init-d-script handler from sysvinit-utils where it is no longer in my 
> control to tune the code (and that's feature, not a bug).

It does seem harmless, but there are issues to discuss before I
believe it is a good idea.

> It seems the init-d-script handler has same "wrong" order in its
> code as the uwsgi-emperor init script had until now, so I hereby
> reassign this bug to sysvinit-utils in the hope they agree it is
> harmless to flip the order of things.

I do not quite get it.  The test in question is intended to make sure
the init.d script is not executed when the binary package is removed
but not yet purged.  The way it is implemented is to check if the
executable from the binary package is present.

For this to be a problem when overriding $DAEMON in
/etc/default/uwsgi-emperor, one do not only have to override the
$DAEMON variable, one also have to _remove_ the executable on disk
that originated from the package with the init.d.  Is this the case
here?  I am not sure if that is a use case we
should support in Debian.

I am unable to se another scenario where the order of these code lines
is a problem.  The $DAEMON value will have the overrided value when
the service is started and stopped.  Where did I misunderstand?

-- 
Happy hacking
Petter Reinholdtsen