Django-1.5 build

[Stephen Gallagher]

-----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 at lists.fedoraproject.org
>>>> 
> Will do so.
>> -- devel mailing list devel at 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-----