Re: Django-1.5 build
On 02/28/2013 12:58 PM, Matthias Runge wrote: Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18. http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm To get this more coordinated, I started a wiki page[1], including all django packages. As far as I knew, if that package is django-1.5 ready, I also made a remark. I still don't like the idea to rename the current python-django package to python-django14 and to make a new package python-django15. The latter may not provide python-django or Django for compatibility reasons. I'd stick with https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name and still try to get python-django14 as new package accepted[2]. I can offer support in changing requirements from python-django/Django to python-django14. Matthias [1] https://fedoraproject.org/wiki/User:Mrunge/django15 [2] https://bugzilla.redhat.com/show_bug.cgi?id=916676 -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
Le Ven 1 mars 2013 17:41, Miloslav Trmač a écrit : (In the recent years, the number of upstreams and packagers that can't or won't support a smooth upgrade path and want to have several versions of the same package installed has noticeably increased, and we may need to react to this by designing a different parallel installation setup and packaging guidelines - but let's not do it by ignoring the current guidelines one package at a time.) IMHO the compat-foo naming convention is much better, as it clearly states the package is ultimately going to the killing block, so people need to migrate away now, while fooxy implies xy is here for the long run and people needn't worry. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
-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
packag...@lists.fedoraproject.org
Will do so.
-- devel mailing list devel@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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
- 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
packag...@lists.fedoraproject.org
Will do so.
-- devel mailing list devel@lists.fedoraproject.org
Re: Django-1.5 build
On Fri, Mar 1, 2013 at 8:56 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
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.
Yes. That's also what
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name
describes.
(In the recent years, the number of upstreams and packagers that can't
or won't support a smooth upgrade path and want to have several
versions of the same package installed has noticeably increased, and
we may need to react to this by designing a different parallel
installation setup and packaging guidelines - but let's not do it by
ignoring the current guidelines one package at a time.)
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
On Fri, Mar 1, 2013 at 2:47 PM, Stephen Gallagher sgall...@redhat.com wrote: 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. Note that the provides/requires are not necessarily tied to package names. There is sufficient prior art - quite a few languages have special ABI/API marker provides/requires while still having an unversioned package name. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Django-1.5 build
Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18. http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu 28 Feb 2013 06:58:36 AM EST, Matthias Runge wrote: Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18. http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm How many Django-based packages are we talking about? Should we be considering putting things together in a side tag before landing in Rawhide? Also, I know at least Review Board is incompatible with 1.5 at this time. They're planning to have a 1.5-compatible release sometime in the next month or so. Looking at the release notes[1], there is a sizeable number of backwards-incompatible changes present in this new version. I think it's going to bite us if we force it straight into Rawhide at this point. Given the way that Django tends to operate (backwards-incompatible releases about every six months with only the current and previous release supported for bugfixes and security), I'm wondering if we shouldn't just drop the 'python-django' package entirely and go with 'python-django14', 'python-django15', etc. from here until eternity, retiring unsupported versions only between upstream releases. This is a policy that would probably also work acceptably for EPEL (CCed). Also, Django 1.5's release notes[2] indicate that it now has support for Python 3.2 and later. I'd strongly recommend that we should be dual-building python3-django15 as well here. [1] https://docs.djangoproject.com/en/1.5/releases/1.5/#backwards-incompatible-changes-in-1-5 [2] https://docs.djangoproject.com/en/1.5/releases/1.5/#python-3-support -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEvWJcACgkQeiVVYja6o6OJNQCdGDMix23UbQaBt54/8qm2pZHH PCMAoIwUySlkccFtXorJH2iJQcAzdtLf =RXfG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
Stephen Gallagher wrote: How many Django-based packages are we talking about? Should we be considering putting things together in a side tag before landing in Rawhide? Add cobbler to the list. Cobbler was forgotten about in Fedora 17 and an update to support Django in Fedora 17 is /still/ sitting in updates-testing. Please make sure all dependent packages have made themselves compatible before you push. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
Hi On Thu, Feb 28, 2013 at 6:58 AM, Matthias Runge wrote: Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. You should introduce a python-django15 package instead and let dependent packages slowly move over. We cannot handle this within a single release timeframe. Every release introduces incompatibilities and upstream projects aren't willing to deal with too many Django versions at a time and move forward slowly. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/2013 02:16 PM, Stephen Gallagher wrote: On Thu 28 Feb 2013 06:58:36 AM EST, Matthias Runge wrote: Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18. http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm How many Django-based packages are we talking about? Should we be considering putting things together in a side tag before landing in Rawhide? Well, looking at my list of ~40 python-django packages, I know by coincidence just a single package to be compatible with Django-1.5 Looking at the release notes[1], there is a sizeable number of backwards-incompatible changes present in this new version. I think it's going to bite us if we force it straight into Rawhide at this point. Given the way that Django tends to operate (backwards-incompatible releases about every six months with only the current and previous release supported for bugfixes and security), I'm wondering if we shouldn't just drop the 'python-django' package entirely and go with 'python-django14', 'python-django15', etc. from here until eternity, retiring unsupported versions only between upstream releases. This is a policy that would probably also work acceptably for EPEL (CCed). 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. Also, IMHO the number of incompatible changes became less and less disruptive in the past, and I see this as maturing of the project. Also, Django 1.5's release notes[2] indicate that it now has support for Python 3.2 and later. I'd strongly recommend that we should be dual-building python3-django15 as well here. Yes, I was thinking about a python3-django feature for F20, as it's absolutely too late for this as a feature for F19, right? As there is at least /usr/bin/django-admin provided by the package, we should decide, if that should be coming from the python3 package, if the python3 version should carry a python3 (or just a 3) in it's name, or what to do else. Matthias [1] https://bugzilla.redhat.com/show_bug.cgi?id=916676 - -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRL4IzAAoJEOnz8qQwcaIWygcIAJ+7J4B+nabmV4eSaMguNmXM F81PcSf/HjLQQSeFi2n3CFfM+ZcYnTbBJ+rDKXmIUDLGRRu6tgtOduX8s4x9oQto 4BshL7njsBK3fEKUFJYY2xoJyEC8fmZbzaQ5uZyM1Tqa88vjo/SSYPluiRUWrtL8 pTt3U/7HN3bU/8byzxLyWxtyaf0z+GJvYYGjZlVN+s+aCOeGbYoi3JFLQZ8ZFI7i sz+96VVxYWY8hm7uHn7xUzuh3LoDsYFvsNuGfmT2zliHkSmGnO5RI18w/kW9sbtG gPWtHhWpV/kIWiJhLxakImWQ0XNZx72T0wXWA+usVqJ7HVe6nhDGl09E+jXasU0= =pDV1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
On 02/28/2013 03:57 PM, Rahul Sundaram wrote: You should introduce a python-django15 package instead and let dependent packages slowly move over. We cannot handle this within a single release timeframe. Every release introduces incompatibilities and upstream projects aren't willing to deal with too many Django versions at a time and move forward slowly. I see your point not to touch any Django-package to change the requirements, but also this will make things more confusing: Django (as F17) is 1.4.x python-django is 1.4.x python-django15 is 1.5 what about Django-1.6? So I'd prefer to have python-django as moving target and fix the release by appending the version. Matthias -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
Hi On Thu, Feb 28, 2013 at 11:22 AM, Matthias Runge wrote: I see your point not to touch any Django-package to change the requirements, but also this will make things more confusing: Django (as F17) is 1.4.x python-django is 1.4.x python-django15 is 1.5 what about Django-1.6? So I'd prefer to have python-django as moving target and fix the release by appending the version. Well, if the current python-django in Fedora is renamed to python-django14 and appropriate provides are added to the EPEL version such that django dependent packages don't have to bother with if else in spec files, you wouldn't need any moving targets at all. The version number will be right there in the package name and it will be obvious which version it is. If Django stops breaking compatibility, we can revisit this. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
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 packag...@lists.fedoraproject.org
Will do so.
- --
Matthias Runge mru...@matthias-runge.de
mru...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRMFu1AAoJEOnz8qQwcaIWUGMIAI5gMvDMb2iwcaLWxwZZsRTN
aVedreypqeUOQzxfqhLkTf6Th6UzYhmZiVAeDE/iZmkZ43ktwemPJwMKBoxvnQEJ
oPuM5ieCi5bT/5EIcV9bnHalqINMTexNpTYqezhM+cseIRd2R2wWFAyWdXfzNQTL
MFDMAdKvSBXmIT+1gQfS3y8nuOnK4IgktlDaWgZJ3Jr5QIctm5riuLJ5HsWHB7/t
Qs0AcXGgI1HfxH+677CZfh0bi4MiLayW/y0Ze+vRxsKLMI4Gz/ZKaes10wF4tYlw
HXd6roWW2kh+LLODwxTdSKogUi6/20eoz7e+Cm3JfDp5COjUtQvEbozVWgtUjPA=
=ZGOC
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
- Original Message -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
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 packag...@lists.fedoraproject.org
Will do so.
- --
Matthias Runge mru...@matthias-runge.de
mru...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRMFu1AAoJEOnz8qQwcaIWUGMIAI5gMvDMb2iwcaLWxwZZsRTN
aVedreypqeUOQzxfqhLkTf6Th6UzYhmZiVAeDE/iZmkZ43ktwemPJwMKBoxvnQEJ
oPuM5ieCi5bT/5EIcV9bnHalqINMTexNpTYqezhM+cseIRd2R2wWFAyWdXfzNQTL
MFDMAdKvSBXmIT+1gQfS3y8nuOnK4IgktlDaWgZJ3Jr5QIctm5riuLJ5HsWHB7/t
Qs0AcXGgI1HfxH+677CZfh0bi4MiLayW/y0Ze+vRxsKLMI4Gz/ZKaes10wF4tYlw
HXd6roWW2kh+LLODwxTdSKogUi6/20eoz7e+Cm3JfDp5COjUtQvEbozVWgtUjPA=
=ZGOC
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Regards,
Bohuslav Slavek Kabrda.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/01/2013 08:41 AM, Matthias Runge wrote:
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.
Na! Nonsense, should be handled by the rename.
- --
Matthias Runge mru...@matthias-runge.de
mru...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRMF9dAAoJEOnz8qQwcaIWBUQH/RgyKvyMZkzKM9jjFkh62y/S
T5moxLJJU0kpjGlg+XoSvv2bpEcYyyEjKNkdBo3rkYFZPn7A6y0LpmhjkyZbECXq
Et7j2UG9MV3gElhFGggyDB82flCvaPvKPT1MkhvtqZ16Zwbjb4dyrLCbW5DOOSwX
TLKI9kt/5GthZhg7aHVYbxCn6j+Sv50efIqYBLAUzaA5ug/E7nJtpGvL4iUBVjm2
wNMkcvKbvuZOayJ4MOuRtEbXQlJNW2LlQN37wx1gT7h8Zxvm3iZ64ne4RrkuBAg8
BcDBa3ZzqUimE3fRgTND5xvHltAry4O2KEAwY2T0NZMqXxN1SJTJ4Tp1+McPizU=
=DXnX
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
