Currently in the hdf5 ebuild we have REQUIRED_USE=" !unsupported? ( cxx? ( !mpi ) mpi? ( !cxx ) threads? ( !cxx !mpi !fortran !hl ) )" due to upstream requirements which makes it impossible to have installed hdf5 libs supporting both cxx and mpi. Furthermore no other language wrapper is thread safe (only plain C library) but this is less important from the point of view of dependencies. I have already tried enabling unsupported USE flag but it doesn't even compile. In portage there are packages that require sci-libs/hdf5[cxx] while for others it is mandatory sci-libs/hdf5[mpi], it is then impossible to support properly external packages depending on hdf5. I would propose to split hdf5 in two ebuilds or to implement two multibuild variants to get something similar to what is available on debian, so we can two parallel installations /usr/include/hdf5/serial/* /usr/include/hdf5/mpi/* /usr/lib64/libhdf5_serial.so /usr/lib64/libhdf5_mpi.so and so on ... The naming above is just a proposal and should be analyzed more carefully. Probably it is better to have totally new names for includes to avoid that badly written code uses a mix of the two versions. Of course this requires a lot of work to patch all packages requiring hdf5. But IMHO there is a great benefit improving/increasing the flexibility of Gentoo.
> Of course this requires a lot of work to patch all packages requiring hdf5. This makes it essentially a non-starter, sorry. It's already hard enough to look after sci packages without doing something like this, and also breaking anyone trying to build packages from source for development without using ebuilds w/ patches.
@sam I have recently worked in a personal overlay to implement what wished here and ported all the ebuilds in portage depending on hdf5 to a multi flavor installation like in Debian. Are you interested in looking at a PR to evaluate it? The changes to the ebuilds, required to support the new layout, are typically quite simple.
