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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
