On Wed, 24 May 2017 13:14:22 +0000 Scott Kitterman <debian@kitterman.com> wrote: > On May 24, 2017 8:30:00 AM EDT, Ben Hutchings <ben@decadent.org.uk> > wrote: > >On Wed, 2017-05-24 at 12:49 +0200, Raphael Hertzog wrote: > >> [ The topic here is maintaining a version X in $foo-backports > >> when > >$foo+1 > >> contains a version higher than X, eg in my case keep maintaing > >> Django 1.8.x in jessie-backports while stretch has 1.10.x ] > >> > >> Hello, > >> > >> let's start a proper discussion based on facts. The other thread > >> has gotten needlessly personal. I want to start with what I said > >> in https://lists.debian.org/debian-backports/2017/05/msg00106.html > >> > >> The reason for the reject of my upload was "please take the > >> version > >from > >> testing, not a version that never was in the archive". But the > >> rules > >> > (https://backports.debian.org/Contribute/) say this: > >> > To guarantee an upgrade path from stable+backports to the next > >stable, > >> > the package should be in testing. > >> > >> Note the "should", it's not a "must". And my upload perfectly met > >> the criteria for that suggestion: my backported package upgrades > >> fine to the next stable. > >> > >> The policy goes further by defining exceptions: > >> > Of course there are some exceptions: Security updates. > >> > >> I initially uploaded a version that was in testing and all the > >subsequent > >> uploads I made were security updates (in the form of upstream point > >> releases). > >> > >> Honestly, I really think that I'm fully in the spirit of the > >> backport policy and that this rejection is unwarranted. > >[...] > > > >I've always understood that the exceptional cases justify > >backporting a newer version that is currently only in unstable, not > >an older version. > > > >I think we should have an additional exception for cases where it > >becomes impractical to backport newer versions but a maintainer is > >willing to support it with important fixes. But from what I've read, > >that doesn't seem to be the case with Django 1.10. > > Other than breaking lots of user applications, no. Agreed. 1.8 *must* remain available. The only supportable route otherwise is to push 1.8 into jessie. > Upgrading from 1.7 in Jessie to 1.10 is highly likely to break user > code (even if it doesn't break things in the archive). 1.8 is a *mandatory* step to get to 1.10 - packages using databases *cannot* upgrade from 1.7 to 1.10 or 1.11 without going via a new release in backports which requires >= 1.8 and then to 1.10 or 1.11. We've had exactly this problem with lava-server. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847277 Upgrades from developer versions of django *must* go via the intermediate django LTS. LTS versions can then upgrade to a developer version or to the next LTS. This upgrade path is completely broken in django: 1.7 -> 1.9 | 1.10 | 1.11 This upgrade path is required for all packages depending on django in jessie: 1.7 -> 1.8 -> 1.9 | 1.10 | 1.11 Critically, at the point where 1.8 is installed a *new upstream release* of that dependency needs to be co-installed to use the functionality in 1.8 and this upgrade *must* complete before 1.9 or later can be installed. Debian released jessie with 1.7 and that is the source of all these problems. 1.7 is a developer release - it's a bit of a dead end as far as upgrades are concerned. 1.7 can only be upgraded to 1.8, no further. 1.8 can then be upgraded to the next LTS or developer releases in between. > Removal would be better. If we can't fix 1.8, we should just get rid > of the backport. Removing the django backport forces the removal of the dependencies that would be broken by letting in 1.10 so what on earth is gained by doing that? Policy is not a stick to bash developers or users. 1.8 needs to stay available in backports at all costs. Anything else makes backports completely unusable. More than that, it makes all packages depending on django in *stretch* RC buggy. So removing 1.8 from jessie-backports would directly cause the removal of dozens of packages from testing and unstable. Packages already in jessie-backports *depend* on python-django >= 1.8 and can no longer work with 1.7. Removal of 1.8 is *not* an option at any cost. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpAoQLknIovh.pgp
Description: OpenPGP digital signature