Re: git: 0a0f7486413c - main - man: Build manpages for all architectures

From: Kyle Evans <kevans_at_freebsd.org>
Date: Thu, 25 Nov 2021 18:13:21 UTC
On Thu, Nov 25, 2021 at 11:14 AM Fernando Apesteguía
<fernape@freebsd.org> wrote:
>
> On Thu, Nov 25, 2021 at 4:57 PM Kyle Evans <kevans@freebsd.org> wrote:
> >
> > On Thu, Nov 25, 2021 at 9:28 AM Fernando Apesteguía <fernape@freebsd.org> wrote:
> > >
> > > On Thu, Nov 25, 2021 at 4:15 PM Kyle Evans <kevans91@ksu.edu> wrote:
> > > >
> > > > On Thu, Nov 25, 2021 at 8:30 AM Andriy Gapon <avg@freebsd.org> wrote:
> > > > >
> > > > > On 25/11/2021 16:23, Baptiste Daroussin wrote:
> > > > >  > On Thu, Nov 25, 2021 at 03:57:41PM +0200, Andriy Gapon wrote:
> > > > > >> Looking at the output I got another thought: do we need architecture sub-dir
> > > > > >> links at all now that we install manpages to a main directory?
> > > > > >> Is there any benefit to having the same manpage in a directory (like man4)
> > > > > >> and its immediate subdirectory (like man4/arm) ?
> > > > > >>
> > > > > > Hardlink not in the same directory is imho a fragile setup anyway, what if a
> > > > > > user has different mount points here, the hardlink would be broken. while there
> > > > > > is little chances someone is doing that, history told me people are doing weird
> > > > > > things and if they haven't yet, they will soon.
> > > > > >
> > > > > > I continue to think this kind of links should be 1/ symlinks, 2/ relative
> > > > > > symlinks if they are in a situation which can become a cross device issue.
> > > > >
> > > > > Yeah... but are they needed at all? :-)
> > > > >
> > > >
> > > > It's handy in the sense that it'd be nice to install all arch manpages
> > >
> > > Not also handy. From the original commit:
> > > ----------
> > >      Building and installing architecture-specific man pages only
> > > raises a number of
> > >      problems:
> > >
> > >       * The https://www.freebsd.org/cgi/man.cgi is incomplete. As an
> > >         example, it does not show results for pae(4). The reason for this is
> > >         that the cgi interface runs on FreeBSD amd64.
> > >
> > >       * In FreeBSD amd64 some manual pages have broken X-refs. See hptrr(4)
> > >         for an example.
> > >
> > >       * Also, we have broken links in our Release Notes. This is a
> > >         consequence of the first point. See
> > >         https://www.freebsd.org/releases/13.0R/hardware/#proc-i386.
> >
> > #1 and #3 are a broken man.cgi, and we should fix it or replace it. #2
>
> I think man.cgi is perfectly able to deal with this. The impression I
> got the first time I asked about this[1] was the problem is that we do
> not ship all the man pages in the released packages. man.cgi can not
> show manpages that are not installed.
>
> [1] https://lists.freebsd.org/pipermail/freebsd-doc/2021-March/035449.html
>

Ok, cool, so your patch basically does the right thing except we don't
need the links. If man.cgi needs the links *and* that they're
installed, then yes, man.cgi is still wrong re: discovering these.

> > is arguably not a real problem, the xref makes it clear it's an i386
>
> I'm sorry, I don't know what you mean here. Do you mean from hptrr(4)
> x-ref it is clear that PAE is a i386 thing?
>

Right, from the context:

     The hptrr driver only works on the i386 and amd64 platforms as it
     requires a binary blob object from the manufacturer which they only
     supply for these platforms.  The hptrr driver does not work on i386 with
     pae(4) enabled.

Thanks,

Kyle Evans