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
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
|
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
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.
filesystem 2010.02-4
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)