~alpine/aports

1

[alpine-aports] Bugs in man and manpages

Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20150817041450.GD2568@newbook>
Sender timestamp
1439784891
DKIM signature
missing
Download raw message
Hello all,
I've run into some issues related to manpages.

1- dangling links to manpages
 I encountered some dangling links in dosfstools-doc, which pointed to
the original, uncompressed, manpages.
Apparently there's a bug in the abuild manpage compression code (lines
1410-1413). While abuild does find and compress the actual manpages,
all the symlinks to the manpages never get updated.

2- translated manpages never get compressed.
A bug in the same code.

Roughly, a fix for these issues could look like this:

	find "$subpkgdir"/usr/share/man/man[1-9]* \
		"$subpkgdir"/usr/share/man/*/man[1-9]* \
		-type f \! -name \*.gz \! -name \*.bz2 2>/dev/null |
		xargs -r gzip -9
	find "$subpkgdir"/usr/share/man/man[1-9]* \
		"$subpkgdir"/usr/share/man/*/man[1-9]* \
		-type l \! -name \*.gz \! -name \*.bz2 2>/dev/null | {
		while read MAN; do
			case "$MAN" in
			(*.gz|*.bz2);;
			(*.[0-9]*)
			ln -s `readlink "$MAN"`.gz "$MAN".gz
			rm "$MAN"
			;;
			esac
			done
		}

Finally, there's an annoyance I have with mdocml.
It's impossible to specify the POSIX manpage if another manpage for the same command/function is installed in the same numeric section.
On Debian, you can have the manpages:
/usr/share/man/man1/ls.1
/usr/share/man/man1/ls.1posix

installed at the same time, and get the POSIX manpage via:
man 1p ls

On Alpine, this fails; the root cause seems to be that if you specify a
section, mdocml insists on looking in
"/usr/share/man/man$SECTION/$COMMAND.$SECTION"


If you have both the Linux and POSIX manpages installed (which I always do),
"man 3 fprintf" gives you the Linux manpage, as would be expected.
But "man 3p fprintf" says "man: No entry for fprintf in the manual."
When I run
 ln -s man3 /usr/share/man/man3p
  man 3p fprintf
I end up getting the Linux manpage, which suggests that there *is* fuzzy matching code, but the logic is backwards.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<20150819102656.66bf85a7@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20150817041450.GD2568@newbook> (view parent)
Sender timestamp
1439972816
DKIM signature
missing
Download raw message
On Sun, 16 Aug 2015 21:14:51 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> Hello all,
> I've run into some issues related to manpages.
> 
> 1- dangling links to manpages
>  I encountered some dangling links in dosfstools-doc, which pointed to
> the original, uncompressed, manpages.
> Apparently there's a bug in the abuild manpage compression code (lines
> 1410-1413). While abuild does find and compress the actual manpages,
> all the symlinks to the manpages never get updated.
> 
> 2- translated manpages never get compressed.
> A bug in the same code.
> 
> Roughly, a fix for these issues could look like this:
> 
> 	find "$subpkgdir"/usr/share/man/man[1-9]* \
> 		"$subpkgdir"/usr/share/man/*/man[1-9]* \
> 		-type f \! -name \*.gz \! -name \*.bz2 2>/dev/null |
> 		xargs -r gzip -9
> 	find "$subpkgdir"/usr/share/man/man[1-9]* \
> 		"$subpkgdir"/usr/share/man/*/man[1-9]* \
> 		-type l \! -name \*.gz \! -name \*.bz2 2>/dev/null | {
> 		while read MAN; do
> 			case "$MAN" in
> 			(*.gz|*.bz2);;
> 			(*.[0-9]*)
> 			ln -s `readlink "$MAN"`.gz "$MAN".gz
> 			rm "$MAN"
> 			;;
> 			esac
> 			done
> 		}

we also need to deal with hardlinks. Maybe something like:


        local previnode= prevname=
        find  "$subpkgdir"/usr/share/man/man[0-9]* \
		-type f \! -name \*.gz \! -name \*.bz2 \
                -exec stat -c "%i %n" {} \; | sort -n \
                | while read inode name; do

                if [ "$inode" = "$previnode" ]; then
                        # update hard link
                        rm "$name"
                        ln "$prevname".gz "$name".gz
                else
                        gzip -9 "$name"
                fi

                previnode="$inode"
                prevname="$name"
        done
                
        find "$subpkgdir"/usr/share/man/man[0-9]* \
		-type l \! -name \*.gz \! -name \*.bz2 \
                | while read symlink; do

                ln -s $(readlink $symlink).gz "$symlink".gz
                rm "$symlink"
        done


> Finally, there's an annoyance I have with mdocml.
> It's impossible to specify the POSIX manpage if another manpage for the same command/function is installed in the same numeric section.
> On Debian, you can have the manpages:
> /usr/share/man/man1/ls.1
> /usr/share/man/man1/ls.1posix
> 
> installed at the same time, and get the POSIX manpage via:
> man 1p ls
> 
> On Alpine, this fails; the root cause seems to be that if you specify a
> section, mdocml insists on looking in
> "/usr/share/man/man$SECTION/$COMMAND.$SECTION"
> 
> 
> If you have both the Linux and POSIX manpages installed (which I always do),
> "man 3 fprintf" gives you the Linux manpage, as would be expected.
> But "man 3p fprintf" says "man: No entry for fprintf in the manual."
> When I run
>  ln -s man3 /usr/share/man/man3p
>   man 3p fprintf
> I end up getting the Linux manpage, which suggests that there *is* fuzzy matching code, but the logic is backwards.

Is this a problem in our config or is it an upstream bug?

> Thanks,
> Isaac Dunham
> 
> 
> ---
> Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
> Help:         alpine-aports+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)