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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
