Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
This is a repeat of a previous bug ( Bug #7101 ), which was fixed but seems to be back two-fold--quadruple results, not just doubles. For example, running `man -k gccmakedep` yields: gccmakedep (1x) - create dependencies in makefiles using 'gcc -M' gccmakedep (1x) - create dependencies in makefiles using 'gcc -M' gccmakedep (1x) - create dependencies in makefiles using 'gcc -M' gccmakedep (1x) - create dependencies in makefiles using 'gcc -M'
chances are you have multiple versions of gcc installed and therefore multiple versions of gcc manpages in MANPATH but i dont know, you neglected to provide `emerge info`
err ... should have been NEEDINFO ... re-open with `emerge info` and sys-apps/man version info :p
Here's what you asked for, I included an etcat -v of gcc as well... wolverine root # emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 8 2005, 04:11:18)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache distlocks sfperms strict" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo ftp://gentoo.mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts avi bash-completion bitmap-fonts bzlib cdr crypt curl dvd dvdr emboss encode esd fam flac fortran gif gpmimlib ipv6 java jpeg kde libwww mad mikmod mmx mmx2 motif mp3 mpeg ncurses network nptl nptlonly ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline rtc sdl slang spell sse sse2 ssl svga tcpd tetex tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY wolverine root # etcat -v sys-apps/man [ Results for search key : sys-apps/man ] [ Candidate applications found : 1 ] Only printing found installed programs. * sys-apps/man : [ I] 1.5p (0) wolverine root # wolverine root # etcat -v gcc [ Results for search key : gcc ] [ Candidate applications found : 16 ] Only printing found installed programs. * sys-devel/gcc : [M ] 2.95.3-r8 (2.95) [M ] 3.1.1-r2 (3.1) [M ] 3.2.3-r4 (3.2) [M ] 3.3.2 (3.3) [M ] 3.3.2-r5 (3.3) [M ] 3.3.2-r7 (3.3) [ ] 3.3.5-r1 (3.3) [M~ ] 3.3.5.20050130 (3.3) [ I] 3.3.5.20050130-r1 (3.3) [M~ ] 3.3.5.20050130-r2 (3.3) [M~ ] 3.4.1-r3 (3.4) [M~ ] 3.4.3-r1 (3.4) [M~ ] 3.4.3.20050110-r1 (3.4) [M~ ] 3.4.3.20050110-r2 (3.4) [M ] 4.0.0_beta20050416 (4.0) [M ] 4.0.0 (4.0) wolverine root #
Just to add to that, the example I gave was to simply illustrate the behavior. I get 4 sets of the same results for just about any keyword. For instance, `man -k concatenate` yields: cat (1) - concatenate files and print on the standard output pnmcat (1) - concatenate portable anymaps strcat (3) - concatenate two strings strncat [strcat] (3) - concatenate two strings tac (1) - concatenate and print files in reverse wcscat (3) - concatenate two wide-character strings wcsncat (3) - concatenate two wide-character strings cat (1) - concatenate files and print on the standard output pnmcat (1) - concatenate portable anymaps strcat (3) - concatenate two strings strncat [strcat] (3) - concatenate two strings tac (1) - concatenate and print files in reverse wcscat (3) - concatenate two wide-character strings wcsncat (3) - concatenate two wide-character strings cat (1) - concatenate files and print on the standard output pnmcat (1) - concatenate portable anymaps strcat (3) - concatenate two strings strncat [strcat] (3) - concatenate two strings tac (1) - concatenate and print files in reverse wcscat (3) - concatenate two wide-character strings wcsncat (3) - concatenate two wide-character strings cat (1) - concatenate files and print on the standard output pnmcat (1) - concatenate portable anymaps strcat (3) - concatenate two strings strncat [strcat] (3) - concatenate two strings tac (1) - concatenate and print files in reverse wcscat (3) - concatenate two wide-character strings wcsncat (3) - concatenate two wide-character strings The problem is the symlinks /usr/local/man and /usr/man being in MANPATH along with the directories they point to (/usr/local/share/man and /usr/share/man respectively) when makewhatis is run. If they are not in MANPATH when makewhatis is run, then `man -k some_keyword` yields the correct results--I deleted the whatis files and ran `export MANPATH=$(echo $MANPATH | sed -e 's!/usr/local/man!!g; s!/usr/man!!g; s!::!:!g;')` followed by `makewhatis -w` and then it worked correctly.
ah i delete those symlinks on my system so i guess that's why i've never noticed :)
I think there might be more to it than that: ~ # man -k lpstat lpstat (1) - print cups status information lpstat (1) - print cups status information lpstat (1) - print cups status information lpstat (1) - print cups status information ~ # echo $MANPATH /usr/local/share/man: /usr/share/man: /usr/share/binutils-data/i686-pc-linux-gnu/2.16/man: /usr/share/gcc-data/i686-pc-linux-gnu/3.4.3-20050110/man: : /opt/blackdown-jdk-1.4.2.01/man: /usr/qt/3/doc/man Interestingly: ~ # strace -f man -k lpstat 2>&1 | grep 'open.*whatis' [pid 22723] open("/var/cache/man/whatis", O_RDONLY|O_LARGEFILE) = 4 [pid 22724] open("/usr/local/share/man/whatis", O_RDONLY|O_LARGEFILE) = 4 [pid 22725] open("/usr/share/man/whatis", O_RDONLY|O_LARGEFILE) = 4 [pid 22726] open("/usr/X11R6/man/whatis", O_RDONLY|O_LARGEFILE) = 4 [pid 22727] open("/usr/local/man/whatis", O_RDONLY|O_LARGEFILE) = 4 [pid 22728] open("/usr/man/whatis", O_RDONLY|O_LARGEFILE) = 4 And: ~ # grep -l lpstat /var/cache/man/whatis /usr/local/share/man/whatis /usr/share/man/whatis /usr/X11R6/man/whatis /usr/local/man/whatis /usr/man/whatis /var/cache/man/whatis /usr/share/man/whatis /usr/X11R6/man/whatis /usr/man/whatis And finally: ~ # ls -li /var/cache/man/whatis /usr/share/man/whatis /usr/X11R6/man/whatis /usr/man/whatis 429 -rw-r--r-- 1 root root 1325182 May 25 18:34 /usr/X11R6/man/whatis 429 -rw-r--r-- 1 root root 1325182 May 25 18:34 /usr/man/whatis 429 -rw-r--r-- 1 root root 1325182 May 25 18:34 /usr/share/man/whatis 30487 -rw-rw-r-- 1 root root 1191609 Jan 5 13:31 /var/cache/man/whatis Three of them are due to symlinks, one of them is due to /var/cache/man/whatis. Phil
Created an attachment (id=61097) [details] Patch that removes searching symlinked directories & displays paths where found This patch makes an assumption, that the symlinked man directories were done for an important reason and should not be simply turned into ordinary directories. So this patch simply ignores any symlinked directory. I have left in one side affect in this patch, the added echo line displays the base paths where the man files have been found. In any production use, that line should be removed or commented out. One question, should apropos be searching the /var/cache/man directories at all since it seems like it would always lead to one extra listing everytime. If not, then we should probably remove the reference to it you can see in the begining of the patch.
we dont want to just trim every symlinked directory w/out any sort of checks the check should be: if (dir is a symlink) and (symlink target is in search path) then ignore symlink else use symlink fi
While comment #8 is probably the most accurate, an easier fix might be to remove /usr/X11R6/man and /usr/man from man-1.5p-search-order.patch altogether.
Couldn't this simply be solved by removing or commenting out MANPATH /usr/local/man MANPATH /usr/man in /etc/man.conf instead of fiddling with the symlinks? man(1) or makewhatis(8) need never look in there anyway if they are symlinks pointing to the real manpaths.
Add: /usr/X11R6/man to the list to comment out/remove since /usr/X11R6 is a symlink to /usr now. With all three commented out I only get one result from apropos. Since such a change should be picked up by etc-update, I think it's ok to put this change into the next release and admins can choose to merge it or not depending on their system.
Commenting out the suggested three entries from man.conf did the job for me. The only other thing to get a clean "man -k" output was that I had to manually remove /var/cache/man/whatis (I have no idea what generated this in the first place - makewhatis doesn't appear to when run "normally".) Could this be automatically removed by the installation, or perhaps an einfo message output suggesting that it is...? Phil
this is a rather annoying and silly bug. Is there any reason not to simply remove the extraneous MANPATH lines from the installed man.conf? I've been living with quadruplicate (!) man pages for a while, and on a hunch finally looked in man.conf and checked for symlinks. i commented out the following lines: MANPATH /usr/X11R6/man MANPATH /usr/local/man MANPATH /usr/man
*** Bug 95674 has been marked as a duplicate of this bug. ***
should be fixed in man-1.6c
