Holger Levsen
2017-05-24 14:50:02 UTC
package: release-notes
x-debbugs-cc: ***@debian.org, debian-***@lists.debian.org
On Wed, May 24, 2017 at 02:53:00PM +0100, Neil Williams wrote:
[...about python-django]
the release notes, to minimize the number of users suffering data loss on a
broken upgrade from jessie to stretchâŠ
(I'm neither convinced this upgrade path is the best we can do nor do
I know anything about the state of django in Debian. So please don't cc:
me, I'm just the clueless messanger trying to make sure this situation
gets at least noted in the release notes.)
x-debbugs-cc: ***@debian.org, debian-***@lists.debian.org
On Wed, May 24, 2017 at 02:53:00PM +0100, Neil Williams wrote:
[...about python-django]
Agreed. 1.8 *must* remain available. The only supportable route
otherwise is to push 1.8 into jessie.
*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.
1.7 -> 1.9 | 1.10 | 1.11
This upgrade path is required for all packages depending on django in
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.
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.
If this indeed is the case and stays the case we ought to document this inotherwise 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 databasescode (even if it doesn't break things in the archive).
*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.
1.7 -> 1.9 | 1.10 | 1.11
This upgrade path is required for all packages depending on django in
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 dependenciesof the backport.
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.
the release notes, to minimize the number of users suffering data loss on a
broken upgrade from jessie to stretchâŠ
(I'm neither convinced this upgrade path is the best we can do nor do
I know anything about the state of django in Debian. So please don't cc:
me, I'm just the clueless messanger trying to make sure this situation
gets at least noted in the release notes.)
--
cheers,
Holger
cheers,
Holger