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

[Tilman Koschnick]

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.

Cheers, Til