On 2020-11-08 03:08, Gilles Filippini wrote:
After a test into a clean chroot I can now confirm this hypothesis.
The loss of the alternative is easily triggered by the reinstallation
of
openmpi-bin
...
It happens when reinstalling mpich as well, if the mpi alternative was
previously set to mpich.
I have no idea how to fix it, other than asking openmpi and mpich
maintainers to take care of the hdf5-mpi.pc slave alternative when it
exists. What do you think?
Probably we should check with the update-alternatives developers first,
they may have some ideas. Certainly they should be able to explain
exactly why installing openmpi-bin or mpich causes the hdf5-mpi
alternative to disappear.
There is a precedent for collecting dpkg triggers and running them all
at the same time late in a dpkg (or apt) run, e.g manpages, dkms.
Otherwise, could request it be done by the openmpi-bin and mpich
packages.
I thought it could be good leave the actual alternatives logic in hdf5,
and put into openmpi-bin.postinst something like
if dpkg -s libhdf5-openmpi-dev >/dev/null 2>&1; then
dpkg-reconfigure libhdf5-openmpi-dev
fi
But at irc #debian-devel they pointed out that won't work: you can't run
dpkg-reconfigure inside postinst since the dpkg lock will be in place.
Another option is to just make a copy of the alternative logic in
libhdf5-openmpi-dev.postinst, copying it to openmpi-bin.postinst. A bit
messy but might get the job done. Figuring out how to set up dpkg
triggers might be tidier.
Drew
