python-django update to Django-1.6

Stephen Gallagher sgallagh at
Tue Nov 26 13:59:47 UTC 2013

Hash: SHA1

On 11/26/2013 08:34 AM, Simo Sorce wrote:
> On Tue, 2013-11-26 at 12:02 +0100, Matthias Runge wrote:
>> On 11/25/2013 06:51 PM, Simo Sorce wrote:
>>> On Mon, 2013-11-25 at 11:24 -0500, Stephen Gallagher wrote:
>>>> This is kind of why I keep coming back to: "Why do we have 
>>>> python-django at all?" I don't really see any reason why we
>>>> shouldn't kill off the python-django package and just carry
>>>> 'python-django15' and 'python-django16' packages with a
>>>> conflict.
>>>> The number of incompatibilities between releases is such that
>>>> I don't think we really want to be forcing upgrades on other
>>>> packages at all. We should just be carrying whichever two
>>>> versions are supported by upstream at any given time.
>>>> Upstream is very good about maintaining bugfixes and security
>>>> fixes in both supported streams.
>>> +1 by changing version the current way, the only ting we can
>>> guarantee is a lot of broken packages all the time.
>> I see your points here and thank you for the feedback!
>> From my experience, it was just a pain to have python-django14
>> and python-django[1]. Introducing one or two other packages
>> python-django15 and python-django16 will make it more difficult
>> for users to update django. How should packages require Django?
>> Just require python-django? Sadly, yum can not handle that
>> properly[1].
>> When dropping python-django as provides/requires, we'd have the 
>> situation packages will require a specific version. That's
>> rather unfortunate, because combination of packages requiring
>> some other python-django-foo package might require a different
>> django version.
>> At least for OpenStack Horizon I can say, we're up to fix
>> compatibility issues with Django-1.6 upstream.
>> Matthias
>> [1]
> Packages should require the latest version they work with. If some
> package is really awesome and supports multiple versions I guess it
> could support a generic python-django.
> It's ok if 2 packages become incompatible this way, they wouldn't
> work anyway with the wrong version of django.

I think Simo has the right idea here. We should drop the standard
"python-django" package at this point and instead have python-django15
and python-django16. Each of those packages should add a virtual
Provides: and Obsoletes: for python-django.

Existing packages with a non-strict version will then default to
upgrading to the absolute latest version (python-django16). If that's
not acceptable to their project, they'll need to release a new update
with 'Requires: python-django15' and things should go back to normal.
In the future, if they update so they work with both
currently-available versions, they can go back to 'Requires:
python-django' and will then work with whichever version the user has
on the system (such as for another project).

Yes, it slightly increases the packager work, but it should give a
better experience for the user... to a point.

Since Django 1.5 and 1.6 cannot presently co-exist on the system,
they'll need to have an explicit Conflicts:. This does mean that users
will have an issue if they end up pulling Django 1.6 as part of an
upgrade and then try to install a package that Requires:
python-django15. We can't automatically remove python-django16, so the
user will have to know to do this manually.
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the devel mailing list