[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

man_MANS install locations

From: Jan Engelhardt
Subject: man_MANS install locations
Date: Wed, 31 Aug 2022 11:01:16 +0200 (CEST)
User-agent: Alpine 2.25 (LSU 592 2021-09-18)


A check was impleneted in rpmlint[1] that verifies that a manual page file such
as "foo.3" has indeed been placed in ${mandir}/man3, and not, say,

Ironically, that check immediately triggered elsewhere in another
package in openSUSE distro, because some "foo.3pm" was located not in
${mandir}/man3pm but ${mandir}/man3. Upon a little research, I find
that e.g. on Solaris/Illumos, *.1m man pages are indeed in
/usr/share/man/man1m and not /usr/share/man/man1.

Given the following fragment, I find that automake 1.16.5
places manpages such (on Linux as well as Solaris):

$ cat
man_MANS = svcadm.1m
$ make install DESTDIR=$PWD/rt
make[1]: Entering directory '/tmp'
make[1]: Nothing to be done for 'install-exec-am'.
 /usr/bin/mkdir -p '/tmp/rt/usr/local/share/man/man1'
 /usr/bin/install -c -m 644 svcadm.1m '/tmp/rt/usr/local/share/man/man1'
make[1]: Leaving directory '/tmp'

Well, at least it is documented behavior:

   File extensions such as ‘.1c’ are handled by looking for the valid
part of the extension and using that to determine the correct
subdirectory of ‘mandir’.  Valid section names are the digits ‘0’
through ‘9’, and the letters ‘l’ and ‘n’.

When running automake on Solaris, placing svcadm.1m into man1 rather
than man1m seems outright wrong.
As for GNU/Linux, what was the rationale to only permit [0-9ln]?
Should automake be relaxed? Should the rpmlint check be adjusted
to cater to the GNU FHS?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]