On Thu, 06 Oct 2016 19:32:31 +0100 Chris Lamb <lamby@debian.org> wrote: > Neil Williams wrote: > > > 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. > > Right, but that's for stretch where the sysadmin will be clearly be > more aware of and/or even looking for issues. I don't want to break > existing systems right now. So how are packages using gunicorn to handle support for both stretch and jessie-backports? Packages in jessie can't be changed, so changes need to take place in backports to prepare for stretch. It makes it very messy for packages to use gunicorn as a dependency. Adding packages from backports should be about preparing for the next stable release. jessie-backports should be close to stretch - that's the requirement for making a backport after all, that the version exists in stretch. The backporting of packages which depend on gunicorn should be a simple rebuild in jessie, not a whole new build carrying backports-specific patches to work around failings in dependencies which are already fixed in stretch. The fact that a backport of gunicorn exists which does not support packages from stretch is just making things difficult for others to backport. Why else has python-django backported 1.8 when packages in Jessie were developed against 1.7? Installing python-django from jessie-backports absolutely does break existing systems - unless those systems also get other updates from jessie-backports via stretch. It's common for updates from backports to require other backports to ensure that the system continues to operate - not that the backport of package A requires that the admin *must not* update package B also from backports or that package A must have a custom backport build which doesn't work in stretch. My package would be in a mad situation of needing a build in jessie-backports that works with newer django but older gunicorn. A build that has *not* been testable in stretch because #839183 has been fixed in stretch. Are the Debian changes in the version of gunicorn in jessie-backports supported by upstream? With it's non-upstream /etc/init.d/ support? django 1.8 is the LTS and 1.7 is unsupported now - equally, gunicorn 19.6.0-2 is not in line with gunicorn upstream and >= 19.6.0-6 has upstream support because it's removed the Debian-specific configuration. That's the version which needs to be in jessie-backports. Please provide a backport of gunicorn 19.6.0-6 whilst it is still in testing or 19.6.0-7 once that migrates into testing. That way, packages using gunicorn in stretch can have the same configuration and can depend on gunicorn >= 19.6.0-6 in stretch and jessie-backports. This is getting urgent now as we need time to test the new gunicorn support upstream and get a new release using gunicorn into stretch before the freeze. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpgiM179hgCn.pgp
Description: OpenPGP digital signature