-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/01/2013 02:56 AM, Bohuslav Kabrda wrote:
----- Original Message ----- On 02/28/2013 05:46 PM, Stephen
Gallagher wrote:
>>>> That seems to be a good proposal for me. Review request is
>>>> here[1], based on the current python-django package.
>>>> Shouldn't be an issue. For EPEL, we have the Django14
>>>> package. This shouldn't change there, but we can think
>>>> about introducing provides: python-django14 there.
>>>
>>>
>>> I'm unclear (based on this and your other reply to the list
>>> which came in about ten minutes later). Are you agreed that
>>> we should drop the 'python-django' package and go to
>>> versioned ones exclusively, or are you proposing that we
>>> would eventually turn python-django15 into python-django
>>> (e.g. when python-django16 arrives).
Actually, I was proposing to have python-django as package to
include every version number, and to introduce a package
python-django%{version-1} package when a new %{version} comes out.
Now, I'm more attracted to rename the python-django package (yeay,
another Django-rename) to python-django14 and to submit a new
package python-django15 for review. When 1.6 comes out,
python-django14 will get deprecated and python-django16 will be
submitted for review. But still, currently, we're carrying
provides like this: Provides: django = %{version}-%{release}
Provides: Django = %{version}-%{release} and also provide
python-django. The question remains, what to do here, ie. which
package should carry those provides. (probably the then renamed
python-django14 package, to make sure, not to break anything.
> I have to disagree with you here. Ideally, we should just have
> one package, python-django, that would be the latest upstream. If
> that is undoable, let's also provide older packages as
> python-django14 etc. But we should still keep the newest Django
> (whichever version that is) in Fedora named python-django. So my
> proposal: - Don't introduce Django 1.5 in Fedora 19, the freeze
> is too close and breakages too many. - Right after branching,
> push Django 1.5 (package python-django) to new rawhide (future
> Fedora 20) with python3-django subpackage. - Work with upstreams
> to get dependent packages fixed before Fedora 20 freeze. - If
> some packages fail to be compatible with Django 1.5 before Fedora
> 20 freeze, just introduce python-django14 package and let them
> use that.
Well, I'm also looking at EPEL here (though I suppose we could just
implement a different solution on that side as well). EPEL has a much
longer life than Fedora releases (and much, much longer than the
Django upstream release maintenance period). So we need to have a plan
in place for how to keep EPEL moving forward sanely. In my humble
opinion, we should break things *once* so that packages learn to make
a dependency on a specific Django version (by doing a Requires:
python-django14) and drop the historical "Django" and unversioned
"python-django" Provides from any of the packages.
Historically, no Django-consuming package that I am aware of has
*ever* successfully moved to the next major Django release without
patching. I'd rather that we always maintain both upstream-supported
releases in Fedora and EPEL. When a package is ready and prepared to
move to the next version, they can change the Requires: line in their
spec file. If we maintain the latest as always being the
"python-django" package, we are resigning ourselves to dealing with
breakage in every cycle.
I agree that it's too late in the Fedora 19 cycle to introduce Django
1.5 as "python-django". The breakage would be enormous. However, it's
still early enough to accept the one-time breakage of retiring
"python-django" and replacing it with "python-django14" and fixing
the
packages that require it to pick its Requires. Then we could land
"python-django15" cleanly.
>>> That's an interesting question... perhaps we should
have both
>>> sub-packages install into %{_libexec} and use the
>>> alternatives system to decide which one gets
>>> /usr/bin/django-admin. That's probably a good question for
>>> packaging(a)lists.fedoraproject.org
>>>
Will do so.
> -- devel mailing list devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlEwsYwACgkQeiVVYja6o6OwFgCeLlSOkhci+9iseAXAzjErt3bY
lLoAnRHQqcCcvJzkvr++UwuFHVdWyEt5
=NVWf
-----END PGP SIGNATURE-----