Previous implementation allowed for only one argument to be passed to
the %pycached macro, which made it impossible to combine it with other macros.
Current implementation allows to pass other macros as arguments to
%pycached.
Example:
%pycached %exclude /path/to/foo.py
For macro expansion limitations, the opposite order is not possible.
That is to be documented in the guidelines:
https://pagure.io/packaging-committee/pull-request/986
Added some tests.
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=1838992
Co-authored-by: Marcel Plch <mplch@redhat.com>
To avoid mock using a local copy of python-srpm-macros from the buildroot cache
and having Python version defined to 3.8 until the cache expires.
Also, other surprises happened in the past, so we stop playing it cool and
actually follow the guidelines here.
%pyhon_provide in python-rpm-macros uses new Lua functions from python-srpm-macros
People have python-srpm-macros pre-installed, and it is not autoupdated,
hence they can have older versions installed and it blows up.
- Hardcode the default Python 3 version in the SRPM macros
- Provide python38-foo for python3-foo and the other way around (future RHEL compatibility)
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1812087
$ rpm --eval '%python_provide python38-setuptools'
Provides: python-setuptools = %{version}-%{release}
Provides: python3-setuptools = %{version}-%{release}
Obsoletes: python-setuptools < %{version}-%{release}
$ rpm --eval '%python_provide python3-setuptools'
Provides: python-setuptools = %{version}-%{release}
Provides: python38-setuptools = %{version}-%{release}
Obsoletes: python-setuptools < %{version}-%{release}
$ rpm --eval '%python_provide python39-setuptools'
$ rpm --define 'python3_pkgversion 39' --eval '%python_provide python%{python3_pkgversion}-setuptools'
To make the implementation of %python_provide easier,
any names starting with "python" or "pypy" are recognized as valid arguments.
Previously, this was an ERROR:
$ rpm --eval '%python_provide pythonista'
%python_provide: ERROR: pythonista not recognized.
Now it is a no-op. The behavior was never documented and the change is
backwards compatible for working spec files.
Usage:
%files
...
%pycached %{python3_sitelib}/foo.py
This will list:
/usr/lib/python3.8/site-packages/foo.py
/usr/lib/python3.8/site-packages/__pycache__/foo.cpython-38{,.opt-?}.pyc
Assuming the Python 3 version is 3.8.
The bytecode files are globbed, their presence is not checked.
This will fail:
%pycached %{python3_sitelib}/foo
error: %pycached can only be used with paths explicitly ending with .py
And so will any of this:
%pycached %{python3_sitelib}/*
%pycached %{python3_sitelib}/foo.*
%pycached %{python3_sitelib}/foo.p?
%pycached %{python3_sitelib}/foo.?y
%pycached %{python3_sitelib}/foo.??
But this will work:
%pycached %{python3_sitelib}/foo*.py
And it will generate the following globs:
/usr/lib/python3.8/site-packages/foo*.py
/usr/lib/python3.8/site-packages/__pycache__/foo*.cpython-38{,.opt-?}.pyc
When used with paths that include Python 3 version, it globs with the version:
%pycached /opt/python3.10/foo.py
Generates:
/opt/python3.10/foo.py
/opt/python3.10/__pycache__/foo.cpython-310{,.opt-?}.pyc
While paths without version have less strict globs:
%pycached /custom/foo.py
/custom/foo.py
/custom/__pycache__/foo.cpython-3*{,.opt-?}.pyc
This will generate a warning in RPM build:
warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc
However it ensures the optimized bytecode is there.
Based on recent changes in 04769fa014,
packagers might want to use:
%{?python_provide:%python_provide python2-foo%{?_isa}}
...for backwards compatibility. However the macro adds obsoletes and
since RPM 4.15, obsoletes with %{?_isa} are not possible:
Only package names are allowed in Obsoletes: Obsoletes: python-foo(x86-64) < ...
To allow such usage, %python_provide now only obsoletes if the argument
does not end with ")".
In rpm 4.15 those are no longer defined.
The meaning of "python" is derived from %__python - and that errors by default
unless user defined.
Example usage:
%global __python /usr/bin/pypy3
...
%files
%{python_sitelib}/foo/
This is mostly used when building Sphinx docs on arched build.
Previously:
PLATFORM=$(python3 -c "import sysconfig; print(sysconfig.get_platform())")
export PYTHONPATH=../build/lib.${PLATFORM}-%{python3_version}
make man
Or:
PYTHONPATH=`realpath ../build/lib.linux*` make
Or:
PYTHONPATH=$(echo $PWD/build/lib.linux-*) make html
Now:
PYTHONPATH=../build/lib.%{python3_platform}-%{python3_version}
Adds the %pypi_source macro, as well as %__pypi_url and
%__pypi_default_extension. This should make references to sources in
PyPI much simpler for nearly all Python packages.
This is to ensure the right linker flags get propagated into binaries
accompanying python packages whenever distutils (or similar, env.
variables provided build flags aware) module is delegated to build them
(e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1541106). Instead of
using "%{__global_ldflags}" as the seed for the respective env. variable
one-off application, which would be a direct parallel to "%{optflags}"
seeding CFLAGS, use rather "${RPM_LD_FLAGS}" and "${RPM_OPT_FLAGS}",
as these are not directly bound to macros out of rpm proper (like
it would have been, e.g., on redhat-rpm-config package otherwise).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Lumir Balhar
Miro Hrončok
Tomas Hrnciar
Fedora Release Engineering
Anna Khaitovich
Igor Gnatenko
Petr Viktorin
Tomas Orsava
Jason Tibbitts
Jan Pokorný
Ville Skyttä
Iryna Shcherbina
Michal Cyprian
Orion Poplawski