HomeClusterLabs Projects

Build: spec: sanitize/generalize approach to Python byte-compilation

Description

Build: spec: sanitize/generalize approach to Python byte-compilation

First, "so that the -libs-devel package is multilib-compliant
(no *.py[co] files)" became stale as of ea6e988e8 at latest:

  • -libs-devel in the comment reference effectively turned into -cts (originally affected files: tests/{fencing/lrmd}/regression.py)
  • "multilib compliancy" is no longer relevant, but for quite some time already, "selecting the right Python for RPM-natively run byte-compiling outside of dedicated directories" is what makes turning such automatism off a wise decision

Another line of the problem is that otherwise beneficial automake's
automatism (heh) normally triggers Python byte-compilation on its
own for _PYTHON-suffixed variables (note that in particular
{_datadir}/pacemaker/tests/cts/CTSlab.py gets omitted with this
automechanism for not complying with this). That indeed should not
override procedures intrinsically aligned with wider system, so we just
cut that off when we know we have these native means at our disposal.

Lastly, we utilize just that whenever we can, which for now means that
with concurrent Fedora and perhaps also EL-based distros (if not now
then likely in the near future), we invoke %py_byte_compile macro
at the locations outside Python specific directories. And in case
we previously had to resort to disabling RPM-native byte-compilation
altogether (i.e. incl. those specific directories) because we could
not detect presence of %_python_bytecompile_extra macro, we also
apply the other macro at cts module specific directory at one such
specific location (site-packages).

Details

Provenance
Jan Pokorný <jpokorny@redhat.com>Authored on Aug 23 2018, 10:18 AM
Parents
rP43f2826696d1: Merge pull request #1564 from mbaldessari/podman-support
Branches
Unknown
Tags
Unknown

Event Timeline