-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I wonder if anyone has a solution to incorrect path-names in byte-compiled python packages.
In the normal dist-utils install step within the context of an rpmbuild, all paths get prepended /var/tmp/buildroot-.../usr/lib/python2.x/site-packages. This causes incorrect stack trace information to be shown.
I'd taken to doing byte-compilation in the %post step to fix this, but I've discovered a much worse effect from this in that all the .pyc and pyo files thus fall outside RPM control, and when removing the package, stay in place, effectively negating the removal (although the translation units are definitely gone...)
Any thoughts?
Alan
On Saturday 01 October 2005 21:17, Alan Milligan wrote:
Any thoughts?
Generate at buildtime and use %ghost in %files (or if you're a pedantic at pushing the packages out faster, then use "touch" to generate dummy placeholders). Then generate in %post.
Actually, Debian Python Policy states to byte compile in post. Probably for the reason you stated.
How many packages have you adopted this policy? And, have you noticed a significant speed impact during install of the packages?
The reason it hasn't been implemented here, is probably based on two reasons:
1. Disk space complaints. (FE likes to %ghost *.pyo) 2. Potential install slowness. (They don't want a repeat of the kernel hardlink stuff.)
On Sat, 2005-10-01 at 13:17 +0000, Alan Milligan wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I wonder if anyone has a solution to incorrect path-names in byte-compiled python packages.
In the normal dist-utils install step within the context of an rpmbuild, all paths get prepended /var/tmp/buildroot-.../usr/lib/python2.x/site-packages. This causes incorrect stack trace information to be shown.
Two solutions: 1) In FC4, there's an rpm script: /usr/lib/rpm/brp-python-bytecompile which performs byte compilation correctly. I believe it will re-compile code that distutils already installed as well. Let this do its job and everything should be fine.
2) To create a spec that works for previous versions of FC you have to recompile the code yourself. Here's a snippet::
%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} [...] %install file=roman.py extradest=%{python_sitelib} fullextradest=$RPM_BUILD_ROOT/$extradest install -m 0644 extras/$file $fullextradest %{__python} -c "import py_compile; py_compile.compile(\ '$fullextradest/$file', \ '$fullextradest/$file' + 'c', \ '$extradest/$file')" %{__python} -O -c "import py_compile; py_compile.compile(\ '$fullextradest/$file', \ '$fullextradest/$file' + 'o', \ '$extradest/$file')"
The variables at top will need some tweaking. In most situations you'll want a for loop instead of simply assigning one value to $file. And you may have to change $extradest if you aren't installing a python module to the sitelib.
I'd taken to doing byte-compilation in the %post step to fix this, but I've discovered a much worse effect from this in that all the .pyc and pyo files thus fall outside RPM control, and when removing the package, stay in place, effectively negating the removal (although the translation units are definitely gone...)
Don't do this! As you've discovered, it's broken :-)
-Toshio
packaging@lists.fedoraproject.org