[Python-modules-team] Packaging Django v1.8 for Sid?
codehelp at debian.org
Tue Nov 8 10:43:10 UTC 2016
On Tue, 8 Nov 2016 10:17:21 +0000
Turbo Fredriksson <turbo at bayour.com> wrote:
> On 8 Nov 2016, at 09:06, Neil Williams <codehelp at debian.org> wrote:
> > Just install and use apt-mark hold to keep at that version. You
> > could also create a local apt repository which has 1.8 instead of
> > 1.10 using tools like reprepro. I routinely script things like that
> > for specific test operations - echo the apt source at a new file
> > 'django.list' in /etc/apt/sources.list.d/, update, install run
> > apt-mark and optionally remove the apt source.
> When I said Horizon was broken, I didn’t mean it was broken just for
> me. It simply don’t work (correctly) with Django 1.10.
That much would be obvious to anyone who has worked with python-django
in the past. When an app hasn't been migrated to the new version of
django, every instance of that app using that version is broken. Please
don't assume that this is unusual or unexpected. I've done my own django
upgrades from 1.4 to 1.6 to 1.7 to 1.8 to 1.9 and to 1.10. My own
package currently uses 1.10 in unstable and 1.8 in jessie-backports. It
is entirely manageable and I see no reason for python-django1.8 to be
in unstable. Equally, I'm a user of python-django in Debian, I'm not
the one who would have to do the work of creating a NEW
This close to the freeze, the only possible chance would be to put a
NEW package into experimental but I'm not aware of any precedent for
using experimental for an *older* version of the package already in
unstable. It would have to be a completely new package or the archive
software would simply delete the 1.8 build as obsolete (in unstable and
testing, it most certainly is obsolete).
> So any “hack” isn’t going to benefit the greater community. We could
> really need 1.8 and/or 1.9 into the official repos so that the Horizon
> deps could be changed with an OR..
As I said, I don't see python-django1.8 being an option for unstable at
this time. Other sources of the package exist at the versions you
require. Your particular app must and will eventually migrate to 1.10
anyway, so a temporary fix on your side is the appropriate solution
instead of the much larger workload of re-introducing an obsolete
version into experimental with the delays which are inherent to such a
process. Packages often take two weeks or more to be accepted as NEW.
This is not just putting a file into a directory, there is a *lot* more
to it than that. One web app which has not yet migrated would seem to
be insufficient to justify that workload. 1.10 was uploaded to unstable
in August and 1.9 had deprecation warnings which could / should have
been handled upstream at the time, dating back to June. The greater
django community is already on 1.10.
Really, just pull in 1.8 from jessie-backports. It is a truly minor
adjustment for a temporary problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Python-modules-team