Bug#953021: libhdf5-mpi-dev: provide links to default mpi (hdf5-mpi.pc)

Drew Parsons dparsons at debian.org
Wed Mar 18 10:32:06 GMT 2020


On 2020-03-18 17:42, Gilles Filippini wrote:
> Gilles Filippini a écrit le 17/03/2020 à 17:59 :
>> 
>> As I understand it now, this is do-able if and only if there is a way 
>> to
>> add a slave to an existing alternative. But I can't find such a way. 
>> Any
>> idea?

Looks like you got an idea before I did on how to do it before I do :)

> I'm almost done, but there is a corner case we have to accept. When:
> 1- Default MPI toolchain for the arch is installed
> 2- The selected 'mpi' alternative points to this default MPI toolchain
> 3- The libhdf5-<mpi>-dev flavor for this default toolchain is NOT 
> installed
> 4- Another libhdf5-<mpi>-dev flavor is installed
> Then the hdf5-mpi.pc slave points to nothing until one of these
> conditions is satisfied:
> * The libhdf5-<mpi>-dev flavor for this default toolchain is installed
> or
> * The 'mpi' alternative points to the MPI flavor corresponding to the
> installed libhdf5-<mpi>-dev.
> 
> Do we agree?


That sounds perfectly reasonable.

That scenario is odd, and very specific. It means the system 
administrator has deliberately chosen to not install the preferred 
hdf5-<preferred_mpi> and to install the non-preferred 
hdf5-<nonpreferred_mpi> instead ("preferred" in the mpi alternatives 
sense).

In those conditions it's reasonable that users of that system should 
need to be specific about which hdf5-mpi they're using, invoking 
"pkg-config --cflags hdf5-<nonpreferred_mpi>" rather than "pkg-config 
--cflags hdf5-mpi".  Their system administrator can still configure 
their preferred hdf5 so they can use "pkg-config --cflags hdf5" to 
access their hdf5-<nonpreferred_mpi>, if they want.

Thanks for sorting through the  alternatives logic.

Drew



More information about the Pkg-grass-devel mailing list