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

On Fri, 23 Feb 2024 13:29:48 +0300
Gleb Popov <arrowd@freebsd.org> wrote:

> 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

FYI:
Not-yet-obsoleted patches uploaded at Bug 277028 [2] include fix
for relocating manpage under /usr/local/man/ into /usr/local/share/man/.

Both version of patches are monolithic patches including updates for
multiple related ports.

The update for relocation was not trivial, but fortunately, not
interferring other changes, so I can cut out the changes from others
easily, if required.

As I'm not a maintainer of any updated ports, not a committer, and not
an insider of nvidia, so whether or not the fix is committed as-is is
on maintainers of each 3 ports.

[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277028

-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>