[Bug 526126] Review Request: python3 - Python 3.x (backwards incompatible version)

bugzilla at redhat.com bugzilla at redhat.com
Mon Jan 11 23:42:59 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=526126

--- Comment #67 from Dave Malcolm <dmalcolm at redhat.com> 2010-01-11 18:42:54 EST ---
(In reply to comment #59)
> (In reply to comment #57)
> > The remaining issues from comment #56:
> > >  - a reviewer needs to go through the full review guidelines on this
> > Looking for a volunteer here.
> 
> I'm unsure, if my practice in packaging is good enought to be sure, this won't
> break the build system, when you import it laterly...
> This is the main reason, what's preventing me a bit from taking this ;-)
> Going throught the review guidelines is not the problem at all...

Bravo!  Thanks for the feedback!


> > >  - anything else I've missed  
> > Does anyone have other concerns?    
> 
> - BR tix tk not needed, because both -devel packages are in BR
I've removed these two.


> - %global vs %define:
>  
> https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define
Fixed; I did a search-and-replace throughout the specfile


> - tools and tkinter contain tests -> should go into tests
"rpm -qlv python3-tools|grep test" shows the majority of these files in these
subidrectories:
- /usr/lib/python3.1/lib2to3/tests subdirectory
- /usr/lib/python3.1/Demo/distutils with just a test2to3 (the latter with many
files)
- /usr/lib/python3.1/Demo/md5test
and a few other files

"rpm -qlv python3-tkinter|grep test" shows the tests in this subpackage are all
below "/usr/lib/python3.1/tkinter/test"

In both cases I've moved the ones listed above into the "test" subpackage. I've
added a requirement to the "test" subpackage for the "tools" subpackage due to
the way the directory hierarchy is set up.


> - tools just contains *.py, but is installed in lib64.
>   I don't see why atm... Otherwise this could be noarch.
>   Probably because there is only one pylibdir.
>   Is it worth adding? I don't think so... Would be great, but probably too
> complicated in new releases.
This sounds like bug 543756.  We've lived with this for Python 2.  I'd prefer
to leave dealing with this as an open RFE, rather than block package import on
it.


> - Why do you force gcc?    
These lines:
  # Force CC
  export CC=gcc
came from Python 2's python.spec, and was introduced in this version
* Wed Nov 12 2003 Mihai Ibanescu <misa at redhat.com> 2.3.2-5
- force CC (#109268)
(way back in the Fedora Core 2 days)
https://bugzilla.redhat.com/show_bug.cgi?id=109268

If I'm reading that bug correctly, it appears that what happened was that the
Makefile (generated by "configure" during the build) would include a reference
to "x86_64-redhat-linux-gcc", rather than to "gcc".  This generated Makefile is
shipped in the RPM (originally in the -devel subpackage, more recently in the
main subpackage; see bug 531901) and is parsed by the "distutils" module.   It
appears that a generated libtool script specialcased detection for "gcc" and
couldn't handle such compiler names.

I've tried removing the lines, and it seems to work fine.  We can reinstate
them if it causes trouble.   (Also, if in the future Unladen Swallow gets
merged into Python 3.x, we may want to build Python 3 with LLVM's compiler
instead of gcc).


Updated specfile: http://dmalcolm.fedorapeople.org/python3.spec
Updated SRPM: http://dmalcolm.fedorapeople.org/python3-3.1.1-10.fc11.src.rpm
Diff: http://dmalcolm.fedorapeople.org/python3-from-3.1.1-11-to-3.1.1-12.diff
rpmlint output as before (see comment #27, comment #28, and comment #38)
Successful scratch build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1915081

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list