-----BEGIN PGP SIGNED MESSAGE-----
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
>>>> 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. 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
>> 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.
>>  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 Sorce * Red Hat, Inc * New York