-----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@lists.fedoraproject.org

Will do so.

...

-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel