FS#18783 - [filesystem] man <foo> => ignoring bogus filename

Attached to Project: Arch Linux
Opened by Digital Kiwi (Kiwi) - Monday, 22 March 2010, 03:38 GMT
Last edited by Thomas Bächler (brain0) - Saturday, 07 August 2010, 19:26 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 17
Private No

Details

[kiwi@lappy:~]$ man kill (03-21 22:21)
man: warning: /usr/share/man/man3x/kill.3p.gz: ignoring bogus filename
[kiwi@lappy:~]$ man system (03-21 22:21)
man: warning: /usr/share/man/man3x/system.3.gz: ignoring bogus filename
man: warning: /usr/share/man/man3x/system.3p.gz: ignoring bogus filename
[kiwi@lappy:~]$ man zlib (03-21 22:21)
man: warning: /usr/share/man/man3x/zlib.3.gz: ignoring bogus filename
[kiwi@lappy:~]$ man libalpm (03-21 22:21)
man: warning: /usr/share/man/man3x/libalpm.3.gz: ignoring bogus filename
[kiwi@lappy:~]$
...
etc.

Apparently it is because of a symlink that core/filesystem 2010.02-4 makes, say folks on IRC.

[kiwi@lappy:~]$ clyde -Qo /usr/share/man/man3x (03-21 22:31)
/usr/share/man/man3x is owned by filesystem 2010.02-4
This task depends upon

Closed by  Thomas Bächler (brain0)
Saturday, 07 August 2010, 19:26 GMT
Reason for closing:  Fixed
Comment by Dan Griffiths (Ghost1227) - Monday, 22 March 2010, 03:45 GMT
Amended bug with package name
Comment by Allan McRae (Allan) - Monday, 22 March 2010, 04:01 GMT
Is this a new issue? That symlink has been there for as long as I can remember.
Comment by Leonid Isaev (lisaev) - Monday, 22 March 2010, 16:57 GMT
No, the issue is old, we just noticed it recently (in the process of evolution, a person digs deeper into man-pages :)).

Anyway, this is the line in filesystem PKGBUILD, which creates the link:
ln -s man3 ${pkgdir}/usr/share/man/man3x
Now, what happens if I want to access a man page from 3p section? For instance:
man 3p umask
The answer is the bogus message in terminal, because from man-db's perspective the 3p page ended up in 3x section.

There are two possible solutions:
1. Do not create man3x, man3p, ...
I guess, the standard only requires man{1-9}
2. Create not man3x, but man3p directory and copy all *.3p.gz pages there
This is similar to what RH/Fedora/SuSe does. But the we need also man{0,1,2}p.

In any case why is there only man3x, but not man1x? I don't see logic.

My personal preference would be just to eliminate the symlink. At least it works on my system and for other users as well (according to forums).

Thanks.
Comment by Feifei Jia (ffjia) - Friday, 16 April 2010, 05:52 GMT
This issue still exists, it's a little annoying...

filesystem 2010.02-4
Comment by Martin Kühne (mar77i) - Thursday, 13 May 2010, 02:03 GMT
Someone come up with a usecase or error message that removing symlinks to man3 would cause trouble. I have tried 3x and 3p manpages without any trouble whatsoever, so I suggest to remove the symlinks from the package unless/until the necessarity of those is proven.
btw a man3p link doesn't exist on the current package

filesystem 2010.02-4 (with the symlink in question removed currently without pacman knowing)
Comment by Sergey (Prikrutil) - Saturday, 07 August 2010, 15:44 GMT
New filesystem 2010.07-1 fixed this bug. Should be closed.

Loading...