discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
* Compiling and packaging mandoc for Arch Linux
@ 2020-11-01 18:32 Eli Schwartz
  0 siblings, 0 replies; only message in thread
From: Eli Schwartz @ 2020-11-01 18:32 UTC (permalink / raw)
  To: discuss


[-- 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 --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-11-01 18:32 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-01 18:32 Compiling and packaging mandoc for Arch Linux Eli Schwartz

discuss@mandoc.bsd.lv

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/mandoc-discuss

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 mandoc-discuss mandoc-discuss/ http://inbox.vuxu.org/mandoc-discuss \
		discuss@mandoc.bsd.lv
	public-inbox-index mandoc-discuss

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.mandoc.discuss


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git