The generator deliberately does not use %{_prefix} in order to avoid
generating provides for packages that set a custom prefix. This is done
to ensure that provides are only generated for paths where the Python
interpreter actually loads modules from.
As we can't use %{_prefix} (which would make it all much simpler), this
commit adds a conditional to look in /app only when the %flatpak macro
is defined, and /usr otherwise.
This should fix provides generation for /app-installed flatpak builds.
The %__python_magic filter suddenly got actually working with file 5.39:
Before:
file.cpython-38.opt-1.pyc: data
After:
file.cpython-38.opt-1.pyc: python 3.8 byte-compiled
Hence, the filter started to pick all Python files regardless of their location.
Later, in the actual generator, paths like this were considered:
/opt/usr/lib/python3.X/...
And generated requirements on python(abi).
We don't actually need to filter the files by file magic,
so we drop it to get the previously accidentally working behavior.
We could choose if the path and magic filters are applied as OR or AND.
However, we don't want either.
We actually want to mach any files in Python directories regardless of their magic.
We *could* filter by file type (and executable bit) for provides,
but that would require us to split the attr files into two.
Running this python script on all possible files is way too expensive.
Some of the packages timeout due to that.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
This package is not being kept up to date, it's hard to maintain and we
will need to tune it from time to time which is painful.
Also removes whole layer of bootstrapping.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>