Gilles Filippini a écrit le 17/03/2020 à 17:59 : > Gilles Filippini a écrit le 16/03/2020 à 17:56 : >> Hi Drew, >> >> Drew Parsons a écrit le 03/03/2020 à 19:43 : >>> Thinking about it, if possible it would be best to have hdf5-mpi.pc >>> managed by update-alternatives, but tracking the mpi alternative. >>> >>> i.e. set up as a slave alternative depending on mpi, that updates if the >>> local system switches mpi from openmpi to mpich. >>> >>> I'm not sure if this can be done cross-package, but good if it can. >>> >>> If it can be done, then the control logic would go in the postinst/prerm >>> of libhdf5-openmpi-dev and libhdf5-mpich-dev rather than libhdf5-mpi-dev. >> >> I'm not sure what you have in mind here. I've just uploaded a new >> release to experimental which should fix #953020. It may covers #953021 >> as well. Please let me know... > > 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?
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? _g.
signature.asc
Description: OpenPGP digital signature
