[Pkg-openmpi-maintainers] Bug#493876: Bug#493876: Bug#493876: openmpi-bin adds conflicting alternative 'mpiexec'

[Dirk Eddelbuettel]

On 5 August 2008 at 21:58, Tilman Koschnick wrote:
| On Tue, 2008-08-05 at 12:52 -0500, Dirk Eddelbuettel wrote:
| > In which case we wouldn't need alternative's for mpiexec?  Sounds too good to
| > be true.  Maybe all MPI variants just handle it via alternatives.  Manuel may
| > know this best.
| 
| I was looking into this some time ago, and gave up in despair...
| 
| Alternatives work well if all participating packages agree on the same
| 'master' alternative and exactly the same 'slaves'. As soon as a package
| deviates from this, things get messy, e.g. it depends on in which order
| you add, remove or change alternatives.
| 
| One example: package A has files a.foo, a.bar and a.baz, and B has
| b.foo, b.bar (but not b.baz). Both agree to handle these files via
| alternatives, using foo as the master link.
| 
| While A is active, we have:
| 
| foo -> a.foo
| bar -> a.bar
| baz -> a.baz
| 
| Now activate B. The result is:
| 
| foo -> b.foo
| bar -> b.bar
| baz -> a.baz
| 
| IIRC, if both packages are removed, we are left with a dangling baz ->
| a.baz... They other way round, going from B to A, would be fine.
| 
| Across MPICH, MPICH2 (never made it into the archive), LAM and OpenMPI,
| a variety of files is handled via alternatives: mpiexec & Co, mpicc &
| Co, headers, man pages... Some spread the files across two packages
| (-bin, -dev), other have only one. Some have mpirun, some mpiexec, some
| both. Some have mpic++, some mpicxx, some mpiCC. Some have a full set of
| man pages, some not.
| 
| I think alternatives would need a thorough redesign to handle things
| like this sanely. Until then, they are only good for very close packages
| (one binary + man page, doing exactly the same in both packages), and
| it's probably not worth the bother banging all MPI implementations into
| the same shape.
| 
| As for the problem with migration brought up by the original poster: In
| a similar situation, we found it was easiest to ignore alternatives
| altogether and ask all users to use the "qualified" binary names, e.g.
| mpicc.openmpi. This way, every user could switch implementations
| conciously, at any time, without being dependent on whatever the admin
| thought the default should be at the time.

Excellent post, thanks Til.  So to mark a corner case: maybe we should just
stick this into a README and be done with it?

Dirk

-- 
Three out of two people have difficulties with fractions.