mumps and mumps-mpi cannot be installed side-by-side about mumps-feedstock HOT 7 CLOSED

Good idea! For reference from debian:

libmumps-5.1.2 has:

/usr/lib/x86_64-linux-gnu/libcmumps-5.1.2.so
/usr/lib/x86_64-linux-gnu/libdmumps-5.1.2.so
/usr/lib/x86_64-linux-gnu/libmumps_common-5.1.2.so
/usr/lib/x86_64-linux-gnu/libpord-5.1.2.so
/usr/lib/x86_64-linux-gnu/libsmumps-5.1.2.so
/usr/lib/x86_64-linux-gnu/libzmumps-5.1.2.so

while libmumps-seq has:

/usr/lib/x86_64-linux-gnu/libcmumps_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libdmumps_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libmpiseq_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libmumps_common_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libpord_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libsmumps_seq-5.1.2.so
/usr/lib/x86_64-linux-gnu/libzmumps_seq-5.1.2.so

I wish I had see this before creating mumps-mpi so that we could have used the same names (mumps is parallel, mumps-seq gets a suffix).

I see a few main options:

1. match debian packages (drop mumps-mpi, mumps package has mpi, no suffix. add mumps-seq package with _seq suffix)
2. keep packages as we've made them (mumps-mpi has _mpi or _par suffix, default mumps has no suffix)
3. keep package names, but match debian libs (mumps-mpi keeps lib names, mumps adds _seq)
4. drop mumps package and only have mumps-mpi and mumps-seq, where mumps-mpi is unmodified, and mumps-seq adds debian's _seq suffix

All of these break some downstream packages, except option 4.

1. seq packages need to update dependencies to mumps-seq, to avoid pulling in parallel builds as a dependency (likely results in segfault). mumps-mpi dependents won't break, but need to update to pull in new builds
2. seq dependents are fine, mumps-mpi packages will fail to load until rebuilt with renamed targets
3. mumps-mpi is fine, but seq dependents will fail to load until rebuilt with new lib names (same as 2., reversed)
4. nothing breaks (yay!) but we create a new package. The mumps package continues to exist but stops updating. mumps-mpi dependents don't need any change, and seq dependents won't break, but will need to update their dependency to get updated builds.

My current inclination is to go with 4, because it's the only one that doesn't break anything. Are there any other preferences? /cc @conda-forge/mumps

from mumps-feedstock.

BTW, @michaelwimmer how did you encounter this? I haven't seen folks running both parallel and seq mumps at the same time before.

from mumps-feedstock.

BTW, @michaelwimmer how did you encounter this? I haven't seen folks running both parallel and seq mumps at the same time before.

Both mumps-mpi (used by e.g. petsc4py) as well as mumps (used by kwant) were installed as dependencies on my system. I then tried to link a C-program by hand to the conda installed mumps and then found out that only (in my case, would depend on installation order) the mpi libraries were present.

Actually, given that both mumps and mumps-mpi are static libraries, none of these packages would actually require mumps/mumps-mpi to be installed during runtime. But once those would be turned into shared libs, there would be a serious problem.

from mumps-feedstock.

Both the sequential version and the mpi version install libraries with the same name, e.g. libdmumps.a. If both versions are installed, the later installed versions overwrites the other one.

I would expect this to be a thing that Conda should know about and would refuse to install the second package because of the conflict. Isn't this one of the killer features of a package manager; that you can't break your system in this way?

from mumps-feedstock.

Conda has a flag for refusing to clobber conflicting files, but it is not enabled by default.

You can get warnings when clobbers would happen with:

conda config --set path_conflict warn

from mumps-feedstock.

Any opinions on which path to take for resolving the conflict? I can have a look at 4. unless folks have other opinions.

from mumps-feedstock.

Option 4 is now implemented in #36, creating a new mumps-seq package that differs from the current serial mumps:

• sequential mumps libraries now have a _seq suffix
• libseq mpi headers are in include/mumps_seq with their original names, instead of being in include with a modified mumps_ name.

from mumps-feedstock.