On Mon, Apr 19, 2004 at 07:26:35PM +0200, Jos Vos wrote:
> I have serious doubts about compiling Python code in brp-... scripts.
> Shouldn't this be under direct control (only) of the %build phase?
It's difficult (if not impossible) to get right in the %build phase.
When you byte-compile a python script, among the things recorded in the
.pyc or .pyo file are the timestamp of the corresponding .py file, and
the path to that file. The python interpreter uses the timestamp to
determine when a file needs to be recompiled, and the path when
constructing error messages.
If you byte-compile in %build, and then install in %install, you may
change the timestamp on the .py file, which breaks the whole thing. If
you byte-compile in the %install phase, you have to fixup the paths if
you don't want error messages to refer to %{_tmppath}/.../*.py when an
error is detected.
The first problem is subtle, because it triggers recompiles on a
deployed system, but if you don't use a program you never notice it.
(If you *do* use a program, you unexpectedly fail RPM verifications and
get SELinux access-denied messages here and there.) The second one just
happens when the packager doesn't know that it's a potential problem
because it's a not-well-publicized part of Packaging Lore.
A fix for both is to use python's compileall module at the end of the
%install phase to go through and recompile all of the .py files in the
buildroot with the right options to fix the second problem, fixing the
first problem as a sort of side-effect.
By now you've probably guessed where I'm going with this -- which is to
say that that's precisely what the brp script we're discussing does.
Nalin
