On Tue, 2013-11-26 at 08:59 -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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
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.
One issue to resolve is how to upgrade to the next version if you have python-django15 and F22 has python-django16 and python-django17, perhaps some clever way of making python-django16 obsolete (instead of conflict) python-django15 once 1.5 is pushed out of the new distro version ?
Simo.