That way, accidentally unpackaged files within are reported as errors.
Currently, when %python_extras_subpkg is used, the egg-info/dist-info directory
is packaged as %ghost. When the main package does not have it,
the RPM build would succeed. The extras packages would have the python3dist()
requires and provides, but the main package would not.
By adding %dir after %ghost, we only package the directory
(which is enough for python3-rpm-generators to process it),
but the files in the directory are not included.
When not packaged in the main package, the RPM build fails.
This is a safeguard against packaging mistakes.
The visible difference is that rpm -ql/repoquery -l would only return the metadata directory.
And the RPM build would fail if .egg-info is a file,
which is only possible with Python < 3.12 for packages using distutils (no extras anyway).
The script ignores symlinks for obvious reasons. Don't return an error
code in that case, though, as it makes the rpm builds fail if there
are symlinks in /usr/bin and `pathfix.py ... /usr/bin/*` is used
(e.g. via %pyproject_install from pyproject-rpm-macros).
of preferring '[[' to '[' in bash scripts. Other changes include
quoting unquoted variables, and explicitly specifying bash as the
interpreter for scripts that use features not defined in POSIX sh
Fixes SC2046, SC3001, and SC2292
Prefer '[] && []' to '[ -a ]' and '[] || []' to '[ -o ]' in tests.
-a and -o to mean AND and OR in a [ .. ] test expression is not well
defined, and can cause incorrect results when arguments start with
dashes or contain !. Moreover binary -a and -o are inherently
ambiguous. test(1) man page recommends to use
'test EXPR1 && test EXPR2' or 'test EXPR1 || test EXPR2' instead.
It corrects warnings [SC2166] spotted by covscan.
1. Error out on unset variables.
2. Implement suggestion made by shellcheck: use "||" instead of "-o"" in test.
Shellcheck also suggested -print0 to avoid ambiguity with filenames with
embedded newlines, but instead use '-exec {} +', which doesn't need xargs but
still passes multiple arguments to a single marshalparser invocation.
(Those issues are unlikely to cause problems in the rpm environment, but it's
nice to be shellcheck-clean to use shellcheck during development.)
Co-Authored-By: Benjamin A. Beasley <code@musicinmybrain.net>
This adds a new `%_python_memoize` macro that caches the values of
various python macros in a lua table based on the current value of
`%__python` / `%__python3`. The Python macros are adjusted to use this
macro for memoization instead of the current approach. This way, the
macros will return values that apply to the _current_ `%__python3` value
when packagers create multi-python specfiles that toggle the value of
`%python3_pkgversion`.
Relates: https://bugzilla.redhat.com/2209055
Co-Authored-By: Miro Hrončok <miro@hroncok.cz>
%py3_install_egg is nonfunctional; setuptools removed the easy_install
entrypoint years ago.
%py3_build_egg is technically functional but has been superseded by
newer macros. Calling setup.py directly is deprecated, and
building/installing eggs to begin with is deprecated.
The macros are not used in any Fedora packages and are broken.
It's time to remove them.
When we added %_smp_mflags here, Petr Viktorin asked the question:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/154#comment-124613
> I couldn't find docs for %_smp_mflags.
> How much of a guarantee is there that it contains no other flags than -j?
My answer was:
> %_smp_mflags is documented in https://rpm-packaging-guide.github.io/
> and used in many other RPM macros in Fedora and upstream everywhere.
> There is no official guarantee that it will never contain anything else,
> but if it does, I assume multiple things would burn.
> I am willing to take that risk.
Turns out, the world did not burn, but packagers do set %_smp_mflags to -lX,
which does not work with compileall.
Fixes https://bugzilla.redhat.com/2179149
Macros like %{python3_sitelib} were evaluated at every instance in the spec
(each time, Python was started, sysconfig was imported...).
When there were many instances (40+), it might have taken more than a minute to parse the spec file.
This way, the macros are defined via %global on first usage.
Every repetitive usage reuses the actual value.
When reviewing https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/291
we have discovered that there is no macronized way to get this part of some paths
and that packagers need to hardcode it as cpython-%{python3_version_nodots}.
This way, we have a standardized macro packagers (and other macros) can use.
