Bug 758486

Summary: mpich2 setting MANPATH="/usr/share/man/mpich2", breaking all mans.
Product: [Fedora] Fedora Reporter: Hin-Tak Leung <htl10>
Component: mpich2Assignee: Deji Akingunola <dakingun>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: alain.portal, cjwatson, dakingun, extras-orphan, notting, pschiffe, segg.gill
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-05 14:55:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hin-Tak Leung 2011-11-29 21:59:39 UTC
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.

Comment 1 Hin-Tak Leung 2011-11-29 22:14:19 UTC
FWIW, I had mpich2 in f15 also, but this problem seems to be newly introduced.

Comment 2 Colin Watson 2011-11-30 12:42:47 UTC
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.)

Comment 3 Colin Watson 2011-11-30 12:44:04 UTC
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 ...

Comment 4 Gilles J. Seguin 2011-12-05 10:51:53 UTC
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

Comment 5 Deji Akingunola 2011-12-05 14:55:59 UTC
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 ***