As this topic comes up, I think the issue is more related to cases where upstream is not willing to support FHS installation. PETSc [1] is one case, openfoam [2] is another example which is currently under review [3]. The issue is that derived projects get used to this case of installation, which then can lead to projects depending those to assume that they are not split in the FHS structure, and require e.g. some example files to configure correctly (SLEPc [4] does this during configure)
This leads to a lot of pain, trying to convince projects to not assume the package is installed the way upstream recommends, but the way some distro prefers. On the other hand, we are not consistent - mpi binaries end up in /usr/lib64/$mpi/bin/ but headers are in /usr/include/$mpi-$arch/. This parallel availability is solved with (environment) modules [5] but as already discussed with respect to modularity, that causes quickly an explosion of possibilities ... [1] https://www.mcs.anl.gov/petsc/ [2] https://openfoam.com/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1816301 [4] https://slepc.upv.es/ [5] https://en.wikipedia.org/wiki/Environment_Modules_(software) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
