Django-1.5 build

Fri Mar 1 14:48:40 UTC 2013

----- 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 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-----
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
Regards,
Bohuslav "Slavek" Kabrda.