From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009
Description of problem:
Within RPMS, Python .pyc modules need to have later timestamps than their
corresponding .py source files, otherwise the modules will be rebuilt when
running as root.
I saw this problem last night with redhat-switch-mail.
I'm filing this under rpm because it seems plausible that it can be solved
generically in the rpm build scripts by touching the .pyc files after the
install step, e.g.,
if [ "$RPM_BUILD_ROOT" != "/" ]; then
find $RPM_BUILD_ROOT -name '*.pyc' | xargs -r touch
[One would of course want to do this correctly, using the %file lists, etc.]
I can envison baroque scenarios where this is not the right thing to do, and one
instead wants the timestamps ordered as they were built, but that is certainly
not the common case.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
$ rpm -q redhat-switch-mail
$ rpm -q --dump redhat-switch-mail | fgrep .py
/usr/share/redhat-switch-mail/functions.py 3522 1064842834
aa759d56161eeaf5799bf175b3c2d51f 0100644 root root 0 0 16836 X
/usr/share/redhat-switch-mail/functions.pyc 3784 1064842834
6e442fe1916b579891b7f057a17523f5 0100644 root root 0 0 0 X
/usr/share/redhat-switch-mail/switchmail_tui.py 3420 1064842834
b6ed9bcc833118ded635eea009b70f0f 0100644 root root 0 0 0 X
/usr/share/redhat-switch-mail/switchmail_tui.pyc 3914 1064842834
f16a29197a281e021091c69fc92dd0b4 0100644 root root 0 0 0 X
$ cd /usr/share/redhat-switch-mail/ ; ls -ltr *py*
-rw-r--r-- 1 root root 3420 Sep 29 09:40 switchmail_tui.py
-rw-r--r-- 1 root root 6290 Sep 29 09:40 switchmail_gui.py
-rw-r--r-- 1 root root 3522 Sep 29 09:40 functions.py
-rw-r--r-- 1 root root 7458 Oct 14 19:00 switchmail_gui.pyc
-rw-r--r-- 1 root root 3904 Oct 14 19:00 functions.pyc
-rw-r--r-- 1 root root 4124 Oct 14 19:32 switchmail_tui.pyc
Sure, rpmbuild scripts might be used to fix this problem.
Unfortunately, I cannot distribut hack around's as default
in helper scripts.
Otherwise, this appears to be a possible build problem with
it's fixed in 0.5.22-2. thanks