Hi Dirk! Am Montag, den 17.12.2007, 16:24 -0600 schrieb Dirk Eddelbuettel: > Are you sure we need alternatives for something like libmpi_cxx.so.0 which > the 'other' (ie LAM) doesn't have?
No. What I currently try to figure out is where the intersection is and create links all unique libs and manage the rest with u-a. > AFAIK update-alternatives is for several implementations of the same file > only. Yes. I think this an unneccessary limitation which makes stuff overly complex to manage for maintainers and confusing for users. But that's a different story. As far as I can see, everything *should* be fine, since all links are created (or should) by u-a. Apparently, this does not happen. I can see why if there are multiple MPI implementations installed (bug #220044) but not why it's a problem when just libopenmpi-dev is installed. MPICH does it exactly the same way, and it seems to work for them for a reason I can't see right now. > Or are you in fact suggesting to use update-alternatives for libmpi.so _and_ > and the same time update all those libmpi_$Foo.so that only appear with Open > MPI ? That, I guess, would still be correct use of alternatives via the > slave. In fact there may or may not be exampel cases from the vi use or some > other u-a use. This is what I thought would work and implemented that. As we can see, it does not work. MPICH is a working example. See above. > Thanks for digging through this! You're welcome! Though I feel like having lost the overview. It may take a little longer than expected. Best regards Manuel
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
