10:29 p.m.
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
3:21 a.m.
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
3:50 a.m.
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
9:37 a.m.
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
12:13 p.m.
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.
--
Stephen J. Smith | sjs(a)khadrin.com | http://khadrin.com/
12:26 p.m.
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)...
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
7:23 p.m.
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
3:29 a.m.
New subject: needswork question
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
7362
days inactive
7363
days old
9 comments
10 participants
participants (10)
-
Bill Nottingham -
Florian La Roche -
Jeremy Katz -
Jos Vos -
Nalin Dahyabhai -
Paul Nasrat -
seth vidal -
Stephen J. Smith -
Tim Waugh -
Zoltan Kota