[arch-dev-public] [signoff] man-pages 3.17-1

Xavier shiningxc at gmail.com
Mon Feb 16 03:20:52 EST 2009


On Sun, Jan 25, 2009 at 3:56 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Sun, Jan 25, 2009 at 5:04 AM, Xavier <shiningxc at gmail.com> wrote:
>> On Sun, Jan 25, 2009 at 10:31 AM, Andreas Radke <a.radke at arcor.de> wrote:
>>> [andyrtr at laptop64 ~]$ locate geteuid
>>> /usr/lib/perl5/core_perl/auto/POSIX/geteuid.al
>>> /usr/share/man/man2/geteuid.2.gz
>>> /usr/share/man/man2/geteuid32.2.gz
>>> /usr/share/man/man3p/geteuid.3p.gz
>>> /usr/share/ri/1.8/system/Process/Sys/geteuid-c.yaml
>>>
>>>
>>> your command is broken in all man-pages versions since 3.00 - are you
>>> sure anything else but "man geteuid"(works here) is wanted and needed?
>
> I chose this one randomly and it happened to blow up on me, so sorry
> for the lucky smoke test. :)
>
> Not so much needed as "if we install something, it shouldn't be
> broken". But with Xavier's comment below about them not all being
> broken...
>
>> Probably not, but this issue is quite weird, there are many others *32
>> man pages that are just simple links, and they all work fine.
>> $ zcat /usr/share/man/man2/geteuid32.2.gz
>> .so man2/geteuid.2
>> $ zcat /usr/share/man/man2/getgid32.2.gz
>> .so man2/getgid.2
>> $ zcat /usr/share/man/man2/getgroups32.2.gz
>> .so man2/getgroups.2
>> ...
>>
>> Yet, only geteuid32 is broken. Very weird.
>
> That is quite odd. What is different about this one that it fails to
> link correctly?
>

Oh I am so stupid, I finally found what the difference is. It breaks
when we have more than 1-level symlink.
lstat64 -> lstat -> stat
geteuid32 -> geteuid -> getuid

Now it doesn't look so odd anymore, good :)

And thanks, you just gave me another argument for pushing for man-db :
http://bugs.archlinux.org/task/9130
It works perfectly fine with man-db.
What's up with a tool for reading man pages that does not even support
their compression? Sounds unbelievable.


More information about the arch-dev-public mailing list