----- Original Message -----
-----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.
What about all the django extension packages? Will there also be python-django-foo[14,15]?
Keeping the old versions around is a huge burden. And even if you admit that it's
going to be just for the necessary time, someone will come and complain that he needs more
time. Also, what about these packages in EPEL? We would have to maintain them for much
longer there...
I don't see a solution for EPEL now, but appending versions to names for Fedora seems
too hacky to me. Also it means that you need to do review for each of those packages (and
the extension packages!) and you need to retire them after some time... I don't really
think that we should go this way.
>>>> 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-----
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Regards,
Bohuslav "Slavek" Kabrda.