While investigating the possibility of adding a mandoc package to the
official repositories for Arch Linux, I noticed that it doesn't
currently compile without patches, which are fixed in CVS but not
released. Any chance of an official release?

Particularly:

- https://cvsweb.bsd.lv/mandoc/configure.diff?r1=1.71&r2=1.72

Do not use make to retrieve a value for $CC, since this is anyways going
to always be "cc" or theoretically the standardized "c99", but in
practice "cc". Badly broken on current versions of GNU make due to
explicitly unsetting $PATH before invoking make, and therefore only
working in environments where "echo" is a $SHELL builtin and the
implementation doesn't optimize simple commands to use execve or
posix_spawn (implementation defined if it resets $PATH to something
sane, on glibc at least, the latter doesn't, and GNU make moved from the
former to the latter).

- various changes for compat_*.c

compile correctly with gcc -fno-common (default in gcc 10)

...

I'm also wondering about this patch:
https://aur.archlinux.org/cgit/aur.git/tree/fix-tbl-segfault.patch?h=mandoc

Fixed a different way in
https://cvsweb.bsd.lv/mandoc/tbl_term.c.diff?r1=1.69&r2=1.70

The current maintainer of the unofficial package mentions:

"right... IIRC these two behave exactly the same (at least for the
inputs I tried) so it can be changed to match upstream"

but I don't know which approach you'd consider "more correct", thought
I'd mention it anyway.

...

Unfixed in the latest development source...

[ -z "${INSTALL_PROGRAM}" ] && INSTALL_PROGRAM="${INSTALL} -m 0555"
[ -z "${INSTALL_LIB}"     ] && INSTALL_LIB="${INSTALL} -m 0444"
[ -z "${INSTALL_MAN}"     ] && INSTALL_MAN="${INSTALL} -m 0444"
[ -z "${INSTALL_DATA}"    ] && INSTALL_DATA="${INSTALL} -m 0444"


What is the purpose of installing these files as non-writable by the
*owner*? By definition, the owner may always achieve write access by a
simple chmod, and the owner permission bits do not affect whether other
users may modify the file... I don't see the point of this restriction
except to inconvenience legitimate uses.

Unfortunately, it is very problematic for creating an official package,
as this prevents stripping the executables or generating debuginfo
packages if the files are not writable during the packaging step.

If it turns out there's no good purpose here, then I can locally hack
around this, but then equally it seems like the defaults should be made
a bit saner.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User