Bugzilla – Bug 1217751
PETSc packaging is broken
Last modified: 2024-04-04 11:13:40 UTC
This is partly a rant, partly a cry for help brought about by trying to build a package that depends on petsc as it appears in Factory. TL;DR it is hell! The various flavours of the PETSc package install their headers and libraries to multiple non-standard locations (even after accounting for mpi paths). For example: * petsc-serial - Headers are in the `/usr/lib64/petsc/3.18.5/linux-gnu-c-opt/include/` dir, they should be somewhere in `/usr/include` - Shared lib is in `/usr/lib64/petsc/3.18.5/linux-gnu-c-opt/lib/`; should be in `/usr/lib64/petsc` at worst. - Pkgconfig file is in `/usr/lib64/petsc/3.18.5/linux-gnu-c-opt/lib/pkgconfig/` where pkgconfig does not even look. Not surprisingly, installing petsc-devel and doing `pkgconfig --libs petsc` does not work. Side note: there is also a bonus 0 byte PETSc.pc file in the same dir. `petsc.pc` should be installed to `/usr/lib64/pkgconfig` - There is a supposedly-arch independent `share` dir in `/usr/lib64/petsc/3.18.5/linux-gnu-c-opt` * petsc-openmpi4-devel (and other mpi/hpc flavours I have not dared to look into) - Headers: `/usr/lib64/mpi/gcc/openmpi4/lib64/petsc/3.18.5/linux-gnu-c-opt/include/` - Shared lib and pkgconfig file: `/./usr/lib64/mpi/gcc/openmpi4/lib64/petsc/3.18.5/linux-gnu-c-opt/lib/` ... You get the idea. There is no predictability to determining paths to headers and libraries when using petsc as a dependency. Obviously, with the above setup, pkg-config goes out of the window and there is nothing to make up for it, no petsc-config binary or such. Imagine that petsc gets update to version 3.20.0, dependent packages have to modify their specfiles to get the include path right again. And please don't tell me to use gymnastics like: ``` %define petsc_version %(rpm -q --queryformat="%%{version}" petsc-openmpi4-devel) %define petsc_path %{openmpi_prefix}/%{_lib}/petsc/%{petsc_version}/linux-gnu-c-opt ``` Partly, I was looking into updating petsc to version 3.20.0, but the specfile scared me a little bit, I won't lie.
Fwiw, I looked at Fedora's petsc package (serial flavour), and both their spec file and paths are: * Headers: `/usr/include/petsc/` * Lib: `/usr/lib64/` * Pkgconfig: `/usr/lib64/pkgconfig/` So it does not have to be the mess we have right now.
It looks like the non-HPC variants of petsc were created with environment support in mind already: ----- %if %{without hpc} %if %{without mpi} %define p_base %{_prefix}/ %else %{?with_mpi:%{!?mpi_family:error "No MPI family specified!"}} %define p_base %{_libdir}/mpi/gcc/%{mpi_family}%{?mpi_vers}/ %endif %define p_prefix %{p_libdir}/petsc/%{version}/%petsc_arch %else ... %endif ------ It even creates a module-file - which unlike with the HPC packages - is not well integrated into the module system and does not amend PKG_CONFIG_PATH. I don't have any stakes in non-HPC builds so when I've added HPC support I left in place what was there to not break things for the original package author. It even creates a module file. It should be easy to remove this extravaganza by looking for occurrences of '%petsc_arch' and eliminating them - like: < %define p_prefix %{p_libdir}/petsc/%{version}/%petsc_arch ---- > %define p_prefix %prefix and: < export PETSC_ARCH=%petsc_arch as well as: < # Module files < mkdir -p %{buildroot}/usr/share/modules/%{name}-%{petsc_arch} < ... < EOF Also, the references to the module files in the %files section would have to be removed.
Thanks for the clarifications, I am working on cleaning this up and updating the package.
Ok, looks like meanwhile you found a way to address this - at least for pkgconfig users which did not require to change the original design and touch the 'scary' bits. I don't have a strong opinion on providing environment support for non-HPC, I'm fine with either solution: if you want to drop this I'm fine as well. Generally, simplifying things and not surprise people is a good thing :)
Hope you don't mind that I'm assigning this to you. It looks like you've work-arounded your issues. Please feel free to simplify the non-HPC bits of petsc.
(In reply to Egbert Eich from comment #5) > Hope you don't mind that I'm assigning this to you. It looks like you've > work-arounded your issues. Please feel free to simplify the non-HPC bits of > petsc. Thanks, I hope to improve work on this over the next couple of weeks or so.