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