Date: Thu, 25 Nov 2021 12:13:21 -0600 From: Kyle Evans <kevans@freebsd.org> To: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= <fernape@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, Ed Maste <emaste@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org Subject: Re: git: 0a0f7486413c - main - man: Build manpages for all architectures Message-ID: <CACNAnaHJ7gVeR%2BecwKotvgWEieks6qXZcjKjjLHB9MKvXsF64Q@mail.gmail.com> In-Reply-To: <CAGwOe2YNBPea4q8W4TewdPEET1WtDaTP6ARZ-R=g-XTUkahAXQ@mail.gmail.com> References: <202106300806.15U86pGq037942@gitrepo.freebsd.org> <20210706090311.aomxh4n45tkpktdc@aniel.nours.eu> <c272868f-8552-d914-9d63-32a4af8e51ce@FreeBSD.org> <20211125142339.zxkjpbohkxk4hete@aniel.nours.eu> <9226a616-d279-9702-f13f-cee7299afc7a@FreeBSD.org> <CACNAnaHrps0-DL0BdM4C0KqoxasrdbBumS20P=L3HQ5yU=KHGA@mail.gmail.com> <CAGwOe2Y=H7EkC56v3o24ifoPmy57f8Kbzo3FKwsHKKiP-xPNEA@mail.gmail.com> <CACNAnaFciM29DeEoentuEeGmCUuUsG66ry8dNRSSC2QZJvVWwA@mail.gmail.com> <CAGwOe2YNBPea4q8W4TewdPEET1WtDaTP6ARZ-R=g-XTUkahAXQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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 Evanshelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaHJ7gVeR%2BecwKotvgWEieks6qXZcjKjjLHB9MKvXsF64Q>