Bug 758486 - mpich2 setting MANPATH="/usr/share/man/mpich2", breaking all mans.
Summary: mpich2 setting MANPATH="/usr/share/man/mpich2", breaking all mans.
Keywords:
Status: CLOSED DUPLICATE of bug 753760
Alias: None
Product: Fedora
Classification: Fedora
Component: mpich2
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Deji Akingunola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-29 21:59 UTC by Hin-Tak Leung
Modified: 2011-12-05 14:55 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-05 14:55:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.