Hide Forgot
Hi, could you *pretty please* split the files /etc/profile.d/mpich2-x86_64.csh /etc/profile.d/mpich2-x86_64.sh into a subpackage, such as mpich2-autoload, as instructed in the MPI packaging guidelines? The current system is troublesome when multiple MPI runtimes are installed. Furthermore, having the MPI compiler commands available is not desired, when one wants to build MPI-aware programs in serial mode (which is also required by the guideline).
If you like, you can add Obsoletes: mpich2 <= mpich2-1.2.1p1-8 in mpich2-autoload, so that the behavior stays the same by default on current installations, however new installs would get the normal behavior (unless -autoload is explicitly installed).
(In reply to comment #0) > Hi, > > could you *pretty please* split the files > > /etc/profile.d/mpich2-x86_64.csh > /etc/profile.d/mpich2-x86_64.sh > > into a subpackage, such as mpich2-autoload, as instructed in the MPI packaging > guidelines? > I'm sorry no. I don't see the need for creating such a subpackage, because I would have made it a hard dependency for the mpich2 main package. I believe users installing mpich2 should 'just' have access to mpicc and friends and mpiexec. > The current system is troublesome when multiple MPI runtimes are installed. What specific troubles are we talking about? > Furthermore, having the MPI compiler commands available is not desired, when > one wants to build MPI-aware programs in serial mode (which is also required by > the guideline). You can simply unload the mpich2 module then, and continue with building in your serial model.
(In reply to comment #2) > (In reply to comment #0) > > Hi, > > > > could you *pretty please* split the files > > > > /etc/profile.d/mpich2-x86_64.csh > > /etc/profile.d/mpich2-x86_64.sh > > > > into a subpackage, such as mpich2-autoload, as instructed in the MPI packaging > > guidelines? > > > I'm sorry no. I don't see the need for creating such a subpackage, because I > would have made it a hard dependency for the mpich2 main package. > I believe users installing mpich2 should 'just' have access to mpicc and > friends and mpiexec. What about users of OpenMPI? I have both OpenMPI and Mpich2 installed (for development reasons), but prefer OpenMPI. These files check to see if an MPI implementation has been already loaded. I unload the Mpich module and load the OpenMPI module in my .bash_profile, but /etc/bashrc re-sources all of the files in /etc/profile.d/ loading the Mpich module yet again (neither module file has a conflict line). Since the above files are not marked noreplace, I have to manually edit them after every Mpich upgrade. > > The current system is troublesome when multiple MPI runtimes are installed. > > What specific troubles are we talking about? See above. > > Furthermore, having the MPI compiler commands available is not desired, when > > one wants to build MPI-aware programs in serial mode (which is also required by > > the guideline). > You can simply unload the mpich2 module then, and continue with building in > your serial model.
(In reply to comment #2) > I'm sorry no. I don't see the need for creating such a subpackage, because I > would have made it a hard dependency for the mpich2 main package. > I believe users installing mpich2 should 'just' have access to mpicc and > friends and mpiexec. > > > The current system is troublesome when multiple MPI runtimes are installed. > > What specific troubles are we talking about? You are making it a PITA for packagers and sysadmins alike, who need to use multiple MPI implementations for a reason or another. There's no sense in not being able to disable automatic loading. Would you be happy with a system where you could only have *one* editor installed, since every package insisted they be the default editor to be used? The resulting outcome would be totally unpredictable; the result would depend on what packages are installed and which module is loaded last. For instance loading another MPI runtime leaves MPICH2 variables in existence in the PATH, which may cause trouble with e.g. build systems that sniff out what kind of a system is used. > > Furthermore, having the MPI compiler commands available is not desired, when > > one wants to build MPI-aware programs in serial mode (which is also required by > > the guideline). > You can simply unload the mpich2 module then, and continue with building in > your serial model. Once again, this is incompatible with the existence of multiple MPI implementations. We hope packages to be built for every one of them that are available in Fedora, not just the one the primary package maintainer is used to.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > What about users of OpenMPI? I have both OpenMPI and Mpich2 installed (for > development reasons), but prefer OpenMPI. These files check to see if an MPI > implementation has been already loaded. I unload the Mpich module and load the > OpenMPI module in my .bash_profile, but /etc/bashrc re-sources all of the files > in /etc/profile.d/ loading the Mpich module yet again Put the commands in .bashrc instead (below the section that sources /etc/bashrc) .bash_profile sources .bashrc, which sources /etc/bashrc, which in turn reads thru /etc/profile.d . My .bashrc look like below and does what you're wanting to do above; >>>> # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # User specific aliases and functions if [ -f $HOME/.profile ]; then if [ -z $ARMNLIB ]; then . $HOME/.profile . /opt/intel/bin/ifortvars.sh intel64 fi fi module unload mpich2-x86_64 module load openmpi-x86_64 <<<<
(In reply to comment #4) > > > > What specific troubles are we talking about? > > You are making it a PITA for packagers and sysadmins alike, who need to use > multiple MPI implementations for a reason or another. There's no sense in not > being able to disable automatic loading. > You are again making broad instantiated claims. Experienced users who want to use multiple MPI implementations can always 'module unload mpich2'. > Would you be happy with a system where you could only have *one* editor > installed, since every package insisted they be the default editor to be used? > That is a wrong analogy to use. A system can have vim, pine, and emacs all installed, and one can use any one of them without mucking with PATHs > The resulting outcome would be totally unpredictable; the result would depend > on what packages are installed and which module is loaded last. > > For instance loading another MPI runtime leaves MPICH2 variables in existence > in the PATH, which may cause trouble with e.g. build systems that sniff out > what kind of a system is used. > I don't see why having MPICH2 variable deep down a PATH is a problem. Any build system that have issues with that needs to be fixed. > > > Furthermore, having the MPI compiler commands available is not desired, when > > > one wants to build MPI-aware programs in serial mode (which is also required by > > > the guideline). > > You can simply unload the mpich2 module then, and continue with building in > > your serial model. > > Once again, this is incompatible with the existence of multiple MPI > implementations. We hope packages to be built for every one of them that are > available in Fedora, not just the one the primary package maintainer is used > to. I'm not forcing mpich2 on anyone, just trying to make it easier to use.
Please reread and rewrite opening paragraphs of http://fedoraproject.org/wiki/Packaging:MPI to indicate that Mpich2 is now the default compiler for Fedora and that the choices of MPI compiler should not be left to the user.
Still in breakage. http://fedoraproject.org/wiki/Packaging/MPI#Packaging_of_MPI_compilers "MUST: If the maintainer wishes for the environment module to load automatically by use of a scriptlet in /etc/profile.d or by some other mechanism, this MUST be done in a subpackage."
mpich2-1.4.1p1-4.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mpich2-1.4.1p1-4.fc16
mpich2-1.4.1p1-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/mpich2-1.4.1p1-4.fc15
Package mpich2-1.4.1p1-4.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mpich2-1.4.1p1-4.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0033/mpich2-1.4.1p1-4.fc15 then log in and leave karma (feedback).
mpich2-1.4.1p1-4.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
mpich2-1.4.1p1-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.