Re: Compiling and packaging mandoc for Arch Linux

[Ingo Schwarze <schwarze@usta.de>]

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