I encountered a problem with the version of automake in Fedora 36, as this problem does not exist in 35 or RHEL9. When configuring a source project designed to build with the GNU automake tools one can specify the option --with-python_prefix in order to specify the directory where the Python packages of this project (if it has any) are supposed to be installed e.g.
./configure --prefix=/opt/apps/my-project --with-python_prefix=/opt/apps/my-project
and in this case the application will be installed in
while the Python packages will be installed in
However, in Fedora 36 the same option results in the Python packages ending up in directory:
So, automake adds the “local” folder to the prefix and this can create a lot of problems because applications may not be able to find the required Python packages.
I assume that this is a bug and not something added to automake on purpose.
Are people aware of that and is there a fix for this problem?
The complete path is usually composed of smaller definitions. For example, the complete python package path would be something like
%python_prefix/%libdir/%python_site_dir (I’m not sure of the names of the macros here, it’s just an example. So, it looks like the definition of one of the macros may have changed in a new version of automake—it’s not necessarily a bug because defaults can change between versions. You can usually set the various macros using configure. For example, the
%configure macro we use in package specs actually expands to this:
# more flags are set before
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
So maybe check what
libdir is set to to begin with? It may be set to
%prefix/local/lib instead of
%prefix/lib, and you should be able to set it explicitly to whatever you wish.
The library path is set automatically from the “prefix” path to:
and so all libraries are installed in the proper directory under the prefix. The same applies to all the other directories i.e. bin, etc, include, share, libexec etc. It is only the Python path which contains this “local” folder.
But you can override the library path using
--libdir, so worth trying that first to see if it works? You can file a bug with the automake maintainers here anyway: