-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlKUqVMACgkQeiVVYja6o6MizwCcCCJfRhc7M7h/pTWwwtVXKZ3d
7EMAn2fA3ktfExNZZZwp1fX2RleWK7rJ
=6Nfr
-----END PGP SIGNATURE-----