help / color / mirror / Atom feed
From: Eli Schwartz <eschwartz@archlinux.org>
To: discuss@mandoc.bsd.lv
Subject: Compiling and packaging mandoc for Arch Linux
Date: Sun, 1 Nov 2020 13:32:26 -0500	[thread overview]
Message-ID: <6fc50edc-3d53-1d9b-4123-8d29728671ed@archlinux.org> (raw)

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


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

Fixed a different way in

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

             reply	other threads:[~2020-11-01 18:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 18:32 Eli Schwartz [this message]
2021-08-14 14:50 ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6fc50edc-3d53-1d9b-4123-8d29728671ed@archlinux.org \
    --to=eschwartz@archlinux.org \
    --cc=discuss@mandoc.bsd.lv \
    --subject='Re: Compiling and packaging mandoc for Arch Linux' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).