python-django update to Django-1.6

Simo Sorce simo at redhat.com
Tue Nov 26 14:31:40 UTC 2013


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
> >> 
> >> 
> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=978647
> > 
> > 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.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list