[Bug 573151] Review Request: python26 - Parallel-installable Python 2.6 for EPEL5

[bugzilla at redhat.com]

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=573151

--- Comment #9 from Dave Malcolm <dmalcolm at redhat.com> 2010-03-17 11:53:44 EDT ---
I discovered a problem with .pyc/.pyo files when attempting to rebuild
python26-setuptools: on the build I did on my RHEL5 workstation, the .pyc files
are incorrectly byte-compiled for 2.4, not 2.6 (the first four bytes are 6d f2
0d 0a, which is a 2.4 bytecode file, when it should be d1 f2 0d 0a for 2.6).

The problem is that RHEL5's /usr/lib/rpm/redhat/macros contains a definition of
%__os_install_post which invokes /usr/lib/rpm/brp-python-bytecompile without
any arguments, which leads to all .py files in a package payload being
byte-compiled with /usr/bin/python (rather than, say, /usr/bin/python2.6)

If there's a mismatching "magic" number, Python can't used the cached bytecode,
and will be forced to recompile the .py file (the bytecode _is_ incompatible),
which is slow; if running as non-root the runtime will have to recompile every
time, since it doesn't have permission to write back the .py file.  If running
as root the file will get written back, leading to noise from rpm -V and
probably SELinux mislabeling woes.

I believe this will affect anyone building any Python modules as RPMs for
non-standard Python stacks on RHEL5.  It looks like IUS builds are affected by
the same problem:  specifically, I looked at 
http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/python26-setuptools-0.6c9-1.1.ius.el5.noarch.rpm
and it too has .pyc files erroneously starting with 0x6d (py2.4), not 0xd1
(py2.6).

I ran into this problem with the Python 3 stack in Fedora, and I wrote an
rpmlint test for it:
https://bugzilla.redhat.com/show_bug.cgi?id=531102
which is in rpmlint upstream as of 0.93

We fixed it in Fedora 13 by fixing rpm-build:
https://bugzilla.redhat.com/show_bug.cgi?id=531117

Changing rpm-build for this is not going to be doable in the context of EPEL,
so it looks like we need to supply a script to do this.

The approach I'm following is to add a new macro file: 
   /etc/rpm/macros.python26
as part of the core "python26" package, containing a reimplementation of
"__os_install_post" intended to be identical to the standard one, except that
it specifies "python26" when invoking "brp-python-bytecompile".

Then every python26-foo module would need to define __os_install_post to use
the alternate implementation.    rpm automatically looks in that directory for
add-on macros, so no further work ought to be necessary.

Hopefully this sounds sane.  It looked like there were no lib vs lib64
differences in the implementation of the macro, but I didn't check on every
architecture.

I've tested this in my build of python26-setuptools, using the macro in this
way in python26-setuptools.spec:
    %define __os_install_post %{__python26_os_install_post}
and when doing so, the .pyc files in the payload correctly begin with byte
0xd1, rather than (incorrectly) with byte 0x6d.

Updated specfile: http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec
Diff versus last specfile:
http://dmalcolm.fedorapeople.org/epel-packaging/from-2.6.4-22-to-2.6.4-23.diff

Updated SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.4-23.el5.src.rpm

Scratch build in Koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2058979

Adds this rpmlint error, which is a false-positive:
python26.i386: E: script-without-shebang /etc/rpm/macros.python26

-- 
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.