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/
pgpdIRukZDsfp.pgp
Description: OpenPGP digital signature