Description of problem: Since upgrading to fedora 16, I started to notice that getting at man pages (e.g. 'man git-svn') does not work. I thought it would just take a while to rebuild the man db/whatis or something, but it appears that's not the case. It appears that mpich2 put a shell script in profile.d, /etc/profile.d/mpich2-x86_64.sh and it loads /etc/modulefiles/mpich2-x86_64 which set MANPATH, which breaks trying to run man on other man pages. Version-Release number of selected component (if applicable): man-db-2.6.0.2-2.fc16.x86_64 mpich2-1.4.1p1-1.fc16.x86_64 How reproducible: Always Steps to Reproduce: 1. install man-db and mpich2 and any other packages with man pages. 2.e.g. 'man git-svn' - nothing appears. 3. Actual results: $ man git No manual entry for git $ man git-svn No manual entry for git-svn $ export | grep MANPA declare -x MANPATH="/usr/share/man/mpich2" Expected results: running "export -n MANPATH" to unset MANPATH gets the desired behavior. Additional info: openmpi also has a corresponding file which set MANPATH, /etc/modulefiles/openmpi-x86_64 but not /etc/profile.d/*, so it is not loaded by default. Please feel free to re-assign to mpich2, but man really should have the defaults ("/usr/share/man") always and regardless of MANPATH and in addition to it.
FWIW, I had mpich2 in f15 also, but this problem seems to be newly introduced.
I disagree, as man-db upstream. The documented semantics in manpath(1) are that you can put a colon at the end of $MANPATH if you want the default manpath to be appended. I don't see a need to change this; mpich2 is doing it wrong and should be fixed. If you set PATH and don't append the system path, things will go wrong too. This is similar. "Don't do that, then." (For the record, I looked briefly at the source code for the old man package, and it seems to behave exactly the same way.)
Incidentally, one way to see that mpich2 is clearly wrong is to run a thought experiment in which there is more than one package on the system setting MANPATH in an /etc/profile.d/ script ...
can we change priority to urgent. screwing MANPATH LD_LIBRARY_PATH LOADEDMODULES environment variables i do not want to see this kind of trivial problems, that is it, that is all. please, fix it, very fast required for boost-mpich2 required for boost-graph-mpich2 required for boost-mpich2-python2 thanks
The problem is caused by the 'environment-module' package for which there is now an update that fixes the problem. *** This bug has been marked as a duplicate of bug 753760 ***