Re: git: 0a0f7486413c - main - man: Build manpages for all architectures
- In reply to: Fernando_Apesteguía : "Re: git: 0a0f7486413c - main - man: Build manpages for all architectures"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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