> Anyways, there are easy ways in Autotools to archieve this, and I can
> craft a patch, if you guide me to the canonical upstream of audit.
And even if you don't patch it, the need to export [1] a PYTHON
variable in the environment is exactly what should be done.
The tragedy of autotools is that people end up expecting everything to
be handled _auto_matically. Where we sit downstream we should never
ever need to worry about configure.ac files coming from upstream. One
of the goals of autotools is to allow upstream to redistribute a
bootstrapped archive, one that has already gone through the various
auto* utilities (and the controversial libtool) with a simple `make
dist`.
In the case of this package, you already _don't_ run the configure
script vanilla:
%configure --sbindir=/sbin --libdir=/%{_lib} --with-python=yes \
--with-python3=yes \
--enable-gssapi-krb5=yes --with-arm --with-aarch64 \
--with-libcap-ng=yes --enable-zos-remote \
--enable-systemd
And I assume you don't complain that audit's configure script doesn't
figure automagically that on Fedora it should --enable or build --with
exactly that configuration. Upstream gives you a choice regarding what
you may take from the build.
Auto-detection works the same, if it doesn't yield the results you
need downstream, you have an escape hatch:
./configure --help
[...]
Some influential environment variables:
[...]
PYTHON the Python interpreter
[...]
There is nothing worrying about having to help the configure script,
in some cases you have to to ensure a reproducible build.
It does suck when you need to apply a similar tweak everywhere, but it
could be something handled by the %configure macro if it starts
showing up in more than just the audit package, or simply as part of
the python-means-python3 change (except that here it's the other way
around, which we probably don't want).
Cheers,
Dridi
[1] preferred way for autoconf would be %configure ... PYTHON=python2
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
