Re: How is mpi-default-dev supposed to work?
Hi again,
Le 24 mars 10 à 10:30, Lucas Nussbaum a écrit :
Is it what will happen in practice? I'm afraid that the opposite
will happen: dpkg may well refuse to install the new package because
a conflicting package is already installed. I believe what we want
to do requires a combination of Conflicts, Provides and Replaces
that will be hard if not impossible to put in place.
dpkg might refuse to do that, but it's apt-get which matters here
Yes, I know that. Sorry for the inaccuracy.
I've made a quick-and-dirty test, it seems apt-get does the right
thing, removing the installed package in favour of the new package, in
both directions. My concerns were therefore not grounded.
Below, I summarize and discuss the various solutions discussed so far.
I draw my conclusions right after this discussion.
Discussion:
___________
To summarize the discussion so far:
_______________________
- solution 1: make mpi-default-dev conflict against the non-default
MPI implementations.
pros: ensures the right implementation is always used.
cons: mpi-default-dev cannot be installed concurrently with the
other lib*mpi*-dev. Means alternatively (un)installing mpi-default-dev
and the non-default implementations when working on various MPI
packages, so some pain for developers. End-users may be annoyed as well.
- solution 2: implement mpicc-default et al. links, install them as
alternatives for mpicc et al. with high priority.
pros: the right implementation is _always_ used in clean build
environment;
mpi-default-dev can be installed together with the non-
default implmentations.
cons: in dirty environments, packages may end-up linked against the
wrong implementation. Specifically, there can be trouble when the
admin has set the alternative manually and the package to build uses
mpicc instead of mpicc.default (i.e., currently, all packages).
- solution 3: raise the priority of openmpi
pros: the right implementation is _always_ used in clean build
environment _for the time being_;
mpi-default-dev can be installed together with the non-
default implmentations.
cons: does not allow for chosing mpich2 as default on some arch
where openmpi exists, bad when a new arch is supported by openmpi (a
transition to change the default for this arch has to be done
immediately).
can link against the wrong implementation on dirty
environments.
- solution 4: set the right alternative in mpi-default-dev's postinst
pros: works, on clean environments;
cons: a package should not set an alternative, it's admin's
territory;
does not prevent the admin to reset the alternative.
Conclusion:
___________
In the end, solution 1 is the most robust, but yields some pain.
Solution 2 is still very robust and is also more flexible.
Solution 3 is less robust and paves the way for trouble.
Solution 4 is not very robust and not politically correct.
Do you agree with me? Is there a consensus that solution 1 is the best?
Best regards, Thibaut.
Reply to: