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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 25, 2021 at 11:14 AM Fernando Apestegu=C3=ADa <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=C3=ADa <fernape@freeb= sd.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> wrot= e: > > > > > > > > > > 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 archit= ecture 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 anyw= ay, what if a > > > > > > user has different mount points here, the hardlink would be bro= ken. 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 de= vice issue. > > > > > > > > > > Yeah... but are they needed at all? :-) > > > > > > > > > > > > > It's handy in the sense that it'd be nice to install all arch manpa= ges > > > > > > 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 hp= trr(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.htm= l > 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 wi= th pae(4) enabled. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaHJ7gVeR%2BecwKotvgWEieks6qXZcjKjjLHB9MKvXsF64Q>