Minor change to with_python3 conditions in specfiles
by David Malcolm
For python packages that build python 2 and 3 subpackages from one
shared src.rpm, the current example on
http://fedoraproject.org/wiki/Packaging:Python#Example_spec_file
has this fragment:
%if 0%{?fedora} > 12 || 0%{?rhel} > 6
%global with_python3 1
...snip...
which was written with the assumption that RHEL 7 onwards will have
Python 3 packaged in the same way as we do in Fedora.
However, over the long lifetime of a RHEL release there will be multiple
upstream Python 3 releases, so RH is thinking of handling Python 3 in
RHEL 7 in a different way to how Fedora does it, to better support the
possibility of multiple Python 3 stacks - though exactly how it's to be
done in RHEL 7 isn't fleshed out yet.
Coming back to Fedora, the above means that I'd like to change the above
to omit the "rhel" clause, so that it reads:
%if 0%{?fedora} > 12
%global with_python3 1
and to make equivalent changes throughout the specfiles in Fedora, so
that such dual src.rpms aren't dual src.rpms in the RHEL context, only
in Fedora.
Thoughts? Hope this sounds sane
Dave
10 years, 10 months
Working towards retiring PyXML
by Toshio Kuratomi
Last week I stumbled upon the fact that the newest python-docutils does not
pass its unittests if PyXML is installed. Looking into the issue brought me
to the conclusion that retiring PyXML may be the best thing to do as rrakus
(the current PyXML maintainer) was interested in doing in February:
http://lists.fedoraproject.org/pipermail/devel/2012-February/163039.html
The main reason to actively rid ourselves of the package as opposed to
simply letting it die a slow death is that the python2 stdlib will replace
its own xml module with PyXML if PyXML is installed. Since PyXML is dead
upstream, the code there is older and buggier than the code in the stdlib
that it is replacing (the root of my docutils unittest failure, for instance).
With dmalcolm's help, I've taken a look at finding all the things using
PyXML and figuring out how possible it would be to Retire PyXML:
https://fedoraproject.org/wiki/User:Toshio/Remove_PyXML#Dep_analysis
Most of the dependent packages are likely false deps. They can all be fixed
just by removing the requires: PyXML from the spec file. But a handful of
packages (9 by my count) actually use PyXML and would be broken by removal.
I'm going to start looking at patches for these but I'm pretty sure that at
least comoonics will require more work and a lot of cooperation from
upstream.
How do people feel about this work?
* Seems generally like a good thing?
* Seems like we can sacrifice comoonics and possibly some of the other
packages on the Coding Required list if they aren't ported in time for
F-18?
* Need to explore other options such as stopping the python stdlib from
replacing its xml module with PyXML and patching our packages that can't
be ported to import pyxml explicitly?
Thanks,
-Toshio
10 years, 10 months
Python 3.3 in Fedora 18
by David Malcolm
It's getting close to the Fedora 18 deadline, but Python 3.3 is in
feature freeze upstream, so I think we ought to try to get it into
Fedora 18
I've created this feature page for the bump of "python3" from 3.2 to
3.3:
https://fedoraproject.org/wiki/Features/Python_3.3
I've started work on packaging it. My plan is to create "python3.3"
branches of all relevant packages within dist-git, and to test the
builds to try to sort out the bulk of the issues (scratch build of the
core python3 src.rpm, and then local builds on a rawhide vm). Once
that's done and (hopefully) all the issues are resolved, we can apply
the changes to "master" and rebuild for real into Koji. Any help would
be greatly appreciated!
Thoughts?
Dave
10 years, 10 months