Re: Call for help: moving manpages to share/man

From: Gleb Popov <arrowd_at_freebsd.org>
Date: Fri, 23 Feb 2024 10:29:48 UTC
On Sun, Jan 21, 2024 at 1:19 PM Gleb Popov <arrowd@freebsd.org> wrote:
>
> Ahoy there fellow porters!
>
> portmgr@ is currently working on switching the directory into which
> man pages are installed from "${PREFIX}/man" to "${PREFIX}/share/man".
> It is quite a tedious process, as you might imagine.
> ...

It's been a month since the initial call was made. Despite the fact
that the separate branch approach didn't really work out, the process
of moving manpages to share/man is still ongoing. I'd like to thank
everyone who sent me PRs and plain patches - they were all integrated
into the main branch and all were helpful for our cause.

Still, there is a lot more to process, so I'm making another call for
help, hopefully more concrete this time.
moin@ created a list of problematic ports [1] along with MAINTAINER
field, so you can quickly find if any of your ports need fixing. In
this list "failed" ports are confirmed to be broken if we change the
default mandir prefix in the framework. The "skipped" ports may
probably be dependent on the "failed" ones, so it is better to deal
with "failed" first.

We have an established ways to fix Autotools and CMake-based ports:
- Autotools ports are generally identified by the presence of
GNU_CONFIGURE=yes knob. To fix such a port one should add
GNU_CONFIGURE_MANPREFIX=${PREFIX}/share knob and fix pkg-plist.
- CMake already defaults to a correct mandir location, so CMake ports
usually have some patching that replaces share/man with man. To fix
such ports it is sufficient to remove that patching and then again fix
the plist.

We don't yet care of Meson ports (although it also should be as simple
as the Autotools case). Feel free to skip them for now.

Finally, there are ports with homegrown ad-hoc build systems. There is
no general way to fix them.

When making a mandir-converting change remember to put "Approved by:
portmgr (blanket)" tag into the commit message. This also means that
if you're fixing someone else's port, you don't need to wait for a
maintainer timeout (although it might be still a good idea to wait for
the feedback if the port in question is complex or the change itself
is big).

Thanks in advance to everyone who will help us in this quest.

[1] https://people.freebsd.org/~bofh/dropzone/manprefix-fail.maintainer.txt