In python packages should the .pyc files be included in the package or not? up2date has them, system-config-users has them, system-config-packages does not, nor does system-config-mouse.
ideas?
-sv
On Mon, Apr 19, 2004 at 09:08:34AM +0100, Tim Waugh wrote:
On Mon, Apr 19, 2004 at 12:41:28AM -0400, Bill Nottingham wrote:
It should be a brp script.
I thought this was going to be turned on a few weeks ago. Was it?
I assume brp-python-bytecompile (which is present) should be being called in redhat-rpm-config but
redhat-rpm-config-8.0.28-1.1.1 Build Date: Sun 15 Feb 2004 09:43:00 GMT
Paul
On Mon, Apr 19, 2004 at 09:08:34AM +0100, Tim Waugh wrote:
On Mon, Apr 19, 2004 at 12:41:28AM -0400, Bill Nottingham wrote:
It should be a brp script.
I thought this was going to be turned on a few weeks ago. Was it?
Someone mentioned that e.g. python-2.2 and python-2.3 would be incompatibel (?? never saw concrete information) and some concerns if the compile script is really ready. Definitely worth a try though.
greetings,
Florian La Roche
On Sun, 2004-04-18 at 23:29, seth vidal wrote:
In python packages should the .pyc files be included in the package or not? up2date has them, system-config-users has them, system-config-packages does not, nor does system-config-mouse.
The .pyc files should probably be included as well as the .py files. And it should be done automatically just like the buildroot stripping policies because it's slightly tricky to do "right". Nalin wrote a brp script to do so a while ago, it just hasn't been integrated into the default rpm config (yet)
Jeremy
On Sun, 2004-04-18 at 23:29, seth vidal wrote:
In python packages should the .pyc files be included in the package or not? up2date has them, system-config-users has them, system-config-packages does not, nor does system-config-mouse.
I don't know, but I will say that I don't like the way the Mailman RPM in FC1 does it. It includes the .pyc files _and_ it has a postinstall script that promptly deletes them all and rebuilds them. This means that "rpm -qV mailman" lists all the .pyc files as changed immediately after the RPM is installed.
On Mon, Apr 19, 2004 at 01:13:15PM -0400, Stephen J. Smith wrote:
I don't know, but I will say that I don't like the way the Mailman RPM in FC1 does it. It includes the .pyc files _and_ it has a postinstall script that promptly deletes them all and rebuilds them. This means that "rpm -qV mailman" lists all the .pyc files as changed immediately after the RPM is installed.
Which is an *extremely* bad packaging pratice, IMHO. The worst rpm's can be recognized by the %post scripts, in most cases :-(.
I have serious doubts about compiling Python code in brp-... scripts. Shouldn't this be under direct control (only) of the %build phase?
I'm a bit afraid too many magical things happen. If you see how all kinds of scripts deal with stripping (see one of my recent postings on the rpm-list, which was never answered b.t.w.) and magically do different things in different cases (unintended, maybe, probably)...
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
Hi,
I submitted a new package in fedora.us QA (python-bibtex). Hoping that FC1 recode package will be updated from rawhide (recode-3.6-9 is buggy), I added the keywords 1 and 2 in the keyword field. My package would work nicely in FC1 if recode were updated. But it isn't, so my package is in the needswork phase because it does not build in FC1. What to do now? Should I remove 1 from keywords? Should I prepare the srpm under FC2 test2? Or should I wait for the FC2 final release and do it there?
Zoli
-
Bill Nottingham -
Florian La Roche -
Jeremy Katz -
Jos Vos -
Nalin Dahyabhai -
Paul Nasrat -
seth vidal -
Stephen J. Smith -
Tim Waugh -
Zoltan Kota