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

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


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

> concept and we reference, e.g., ports manpages that are inherently
> broken with some frequency anyways; see: `find *bin | xargs  mandoc
> -Tlint | grep Xr`, a subset of those are ports, although I haven't
> counted.
>
> >
> > Would anyone try this patch
> > https://people.freebsd.org/~fernape/fix-dnoroot.patch?
> >
> > It seems to work(around) the problem, at least with:
> >
> > makefs -D -B little -o label=FreeBSD_root -o version=2 ufs.part METALOG
> > and
> > tar -c -f archive.tbz  @METALOG
> >
> > Cheers.
> > > on some machines, e.g., I develop arm stuff on amd64 and there are
> > > some drivers that simply aren't applicable to amd64, I'd like to be
> > > able to find those. I think the implementation is a bit odd, though,
> > > leading into:
> > >
> > > > I mean, whichever way we install manpages they are always installed into manX.
> > > > I do not see a point / benefit of having another copy / link / whatever in
> > > > manX/arch.
> > > >
> > >
> > > I guess I haven't read the context much here, but I don't see why
> > > either. /usr/bin/man's built-in search behavior checks
> > > $mandir/$machine and $mandir/$machine_arch before $mandir, it seems
> > > like we should be leaving them there and letting man do its thing. If
> > > you need a non-native arch then you can hopefully just poke around the
> > > arch subdirs (presumably mostly section 4 pages) to figure it out.
> > > There's a reason they're arch subdirs, and trying to install links or
> > > arch-specific pages into the main $mandir is asking for trouble when
> > > we actually have conflicting pages for whatever reason between archs.
> > >
> > > Thanks,
> > >
> > > Kyle Evans