Compiling and packaging mandoc for Arch Linux

Compiling and packaging mandoc for Arch Linux

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2598 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1601 bytes --]

Re: Compiling and packaging mandoc for Arch Linux

[Ingo Schwarze]

Hi Eli,

Eli Schwartz wrote on Sun, Nov 01, 2020 at 01:32:26PM -0500:

> 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?

i'm currently working through forgotten feedback since i'm trying again
to prepare the next mandoc release; package maintainers will be asked
for testing once we are ready for that.

> Particularly:
> - https://cvsweb.bsd.lv/mandoc/configure.diff?r1=1.71&r2=1.72
[...]
> - various changes for compat_*.c
> compile correctly with gcc -fno-common (default in gcc 10)
> ...

Everything already committed to CVS HEAD will automatically be in the
upcoming release.

> 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.

The bsd.lv fix is more robust.

> 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*?

Protection against accidental damage that might occur when an
administrator does some work as root.  It is standard practice in
*BSD to install system-installed files that are not supposed to be
changed at run time as non-writeable.  Just because an administrator
uses a root shell for some work does not imply they want to change
the content of system binaries.

> 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.

Needless to say, this is not a security feature, but part of a
defence-in-depth strategy against accidental mistakes.

Changing the content of installed system binaries almost never makes
sense even for a system administrator, and in the rare cases where
it is attempted, i believe it is almost invariably unintentional.

> 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.

I regularly use the OpenBSD packaging system but never encountered
such a problem while porting any software.  I'm not too familiar
with the internals of packaging systems, though.

> 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.

I think installing system binaries non-writeable is quite sane,
and i have no intention of changing that.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv