mpich2 violates the MPI packaging guidelines by placing alternatives in the main package, which is explicitly forbidden. Alternatives *MUST* be placed in a subpackage, that does not need to be installed on a system.
Note that the alternatives support is also currently broken - you need to put in a ld.so.conf.d file to make the mpich2 libraries visible. Currently it is working just because of bug #559018.
(In reply to comment #1) > Note that the alternatives support is also currently broken - you need to put > in a ld.so.conf.d file to make the mpich2 libraries visible. Currently it is > working just because of bug #559018. Well, I don't see it as a bug. Upstream designed the package (using rpath) exactly for that reason. I will talk with upstream and co-ordinate with them about the possibility of removing the rpath and re-introducing the creation of the file in ld.so.conf.d. I don't see the reason for creating a subpackage for alternative support, I'm going to petition the Fedora Packaging Committee for that; the overall Fedora packaging guildeline support it, and I don't personally see the reason why the MPI guildeline should sideline it.
(In reply to comment #2) > (In reply to comment #1) > > Note that the alternatives support is also currently broken - you need to put > > in a ld.so.conf.d file to make the mpich2 libraries visible. Currently it is > > working just because of bug #559018. > > Well, I don't see it as a bug. Upstream designed the package (using rpath) > exactly for that reason. I will talk with upstream and co-ordinate with them > about the possibility of removing the rpath and re-introducing the creation of > the file in ld.so.conf.d. Rpaths are explicitly not wanted in Fedora. The LD_LIBRARY_PATH environment variable set by the environment module takes care of the libraty paths. > I don't see the reason for creating a subpackage for alternative support, I'm > going to petition the Fedora Packaging Committee for that; the overall Fedora > packaging guildeline support it, and I don't personally see the reason why the > MPI guildeline should sideline it. Then please do so. The situation against alternatives in MPI is very clear - alternatives can't be used on user level, unlike environment modules. And you can make the environment module behave exactly in the same way as alternatives, just by placing a file in /etc/profile.d that loads the relevant environment module automatically when you open a session.
(In reply to comment #3) > > Rpaths are explicitly not wanted in Fedora. Not as explicit, there are exceptions. MPICH2 binaries and libraries themselves are not linked with rpath, both the compiler scripts uses rpath for what can be considered as its 'internal use'. However since these compilers are now used to build other packages for Fedora, there is definitely now a need to look at its use. > The LD_LIBRARY_PATH environment > variable set by the environment module takes care of the libraty paths. > > > I don't see the reason for creating a subpackage for alternative support, I'm > > going to petition the Fedora Packaging Committee for that; the overall Fedora > > packaging guildeline support it, and I don't personally see the reason why the > > MPI guildeline should sideline it. > > Then please do so. The situation against alternatives in MPI is very clear - Not so clear, please stop using these strong wordings. Maybe you want to say alternatives can't be easily manipulated on user level, it definitely can be used on user-level and it well suited for workstation installations and single-user systems (which systems Fedora is more suited for). Besides the alternatives systems is being used on various other distros successfully. There is no real technical reason to not include support for it for those who want it, the environment module support is there for others who don't want/need it. > alternatives can't be used on user level, unlike environment modules. And you > can make the environment module behave exactly in the same way as alternatives, > just by placing a file in /etc/profile.d that loads the relevant environment > module automatically when you open a session.
(In reply to comment #4) > > Then please do so. The situation against alternatives in MPI is very clear - > > Not so clear, please stop using these strong wordings. Maybe you want to say > alternatives can't be easily manipulated on user level, it definitely can be > used on user-level and it well suited for workstation installations and > single-user systems (which systems Fedora is more suited for). Besides the > alternatives systems is being used on various other distros successfully. > There is no real technical reason to not include support for it for those who > want it, the environment module support is there for others who don't want/need > it. That's why alternatives are still allowed, but only in a subpackage so that they don't mess up systems with many MPI runtimes installed. In that case you end up with all sort of crazy stuff happening, such as the wrong runtime libraries being (e.g. libmpi.so) picked up and causing hard-to-debug errors. RHEL doesn't use alternatives, either, for the very same reasons. Instead of environment modules they went for mpi-selector, which is a system a lot like environment-modules, only more limited and less commonly used.
ping.
*** Bug 542749 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This seems to have been fixed in 1.2.1p1-1. Thanks!