On Mon, 03 Oct 2016 17:42:32 +0100
Chris Lamb <la...@debian.org> wrote:

> Neil Williams wrote:
> 
> > We're testing this sysVinit support at the moment, seems to work at
> > this end.  
> 
> Thanks. Can you elaborate on the double invokation of
> start-stop-daemon? Namely, is that really needed here?

I thought that was standard init script behaviour, to call first with
--test and then with the options.
 
> > One problem we have identified so far is that these conffiles were
> > removed in 19.6.0-3 but jessie-backports only has 19.6.0-2~bpo8+1.
> > This results in two gunicorn services on jessie using
> > jessie-backports.  
> 
> Indeed…
>  
> > Once 19.6.0-6 gets into stretch, could we have an updated backport
> > please?  
> 
> … I previously hesitated to do that as it would be a real world
> regression for people using Debian stable; their service would simply
> stop working. Okay, stable-with-backports, but you get the idea.

> Can you convince me otherwise?

The users will get the same regression when upgrading to stretch. At
least with the change in backports there is time for packages to also
arrange their own support in backports. There is also time to get those
fixes into stretch. If you are not planning on carrying the init script
from 19.6.0-2 into stretch then the transition has to be done between
jessie and stretch. jessie-backports at least provides support for
those packages that do migrate to the new gunicorn support to allow
them to have working gunicorn support when those packages upgrade after
the stretch release.

If 19.6.0-2 had been an update to jessie in the 8.5 point release,
then retaining the init support would be correct but backports is all
about new features, preparations for migration and allowing changes
which have no place in a point release. 

The only other way to do this is a full reversion to the init support
available in jessie as a new upload to be released in stretch and then
do a full migration, with the examples and plenty of time, for buster.

It might be enough for packages already in jessie and stretch to detect
the executable mode of /etc/init.d/gunicorn but that only works during
package build. So having a usable version of the stretch package in
jessie-backports (without /etc/init.d/gunicorn) allows packages to
build for jessie and stretch/jessie-backports on the presumption that:

if [ ! -x /etc/init.d/gunicorn ]; then
        dh_installinit our_gunicorn
fi

Providing /etc/init.d/gunicorn in jessie-backports doesn't actually
help anyone prepare for stretch.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpdIRukZDsfp.pgp
Description: OpenPGP digital signature

Reply via email to