Nick Coghlan <ncogh...@gmail.com> added the comment:
Now I'm wondering if the problem will also manifest itself on EL rebuilds like
CentOS or Scientific Linux, since that will affect how specific we can get when
it comes to implementing a workaround.
That is, overriding __os_install_post should definitely work, but the question
then becomes how we decide that overriding it is *necessary*, such that:
- we don't bypass vendor hooks when they aren't broken (e.g. Fedora, hopefully
a future version of RHEL)
- we *do* bypass them when we know they don't work properly for Python 3
projects (e.g. RHEL6, probably EL6 rebuilds)
I'm currently thinking of something like this:
# At the top of the bdist_rpm command file
try:
# Support workaround for #14443 which affects some RPM based systems
# such as RHEL6 (and probably derivatives)
from rpm import expandMacro as _expand_rpm_macro
except ImportError:
_expand_rpm_macro = None
# When generating the spec file
if _expand_rpm_macro is not None:
# We're on a system with a vendor installed rpm library
# and at least RHEL6 tries to bytecompile Python modules
# with the system Python instead of the running one
problem = "brp-python-bytecompile \\"
fixed = "brp-python-bytecompile %{__python} \\"
vendor_hook = _expand_rpm_macro("%{__os_install_post}")
fixed_hook = vendor_hook.replace(problem, fixed)
if fixed_hook != vendor_hook:
# Add fixed_hook to spec file template
Thoughts?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14443>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
