From nobody Thu Nov 25 15:27:01 2021 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 810C218A8030; Thu, 25 Nov 2021 15:28:12 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J0MG42fh1z4T8S; Thu, 25 Nov 2021 15:28:12 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: by mail-qk1-f182.google.com with SMTP id g28so12033284qkk.9; Thu, 25 Nov 2021 07:28:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mO9bvwHR1Ult8OBXyXi++fcLrTKQhJl8euwBbSWUgHw=; b=GAhJhsisuRS3Y+d+Wur+AxGLwe/vpprMwqiw24khDb+ULBd+qVYlb0VsXbre5Y/UBX 6B7vH+L/WdsuM06ltm1A4CAmB644oW2JiH9XefSr8Cbt9fxE2S9Er/gkDQM29Ud5oAL+ hbOiKURkhCnfBjPllDgu0L3F3mDoS09HBsx+pTCA0Ts/7vAcO/Etw5MfLIs+gNTdJZz8 UgCa+K85pfSc9Fwq/FG/axGeIdQQPxp9SCYDiMsdd7R+Ed4uBqJ8xzQnNPkLEwmqp0kl sZzryI2k2fAVWc4KfAexiE2bgIma0KJ6PIl5ZUEiUCoj4FMIp5iz1ouc6Hi43JcJZl6Y QIxg== X-Gm-Message-State: AOAM5321w0QkEzVioSVn0BQd+31iz5V8dJD3Sl8czlxFbUE0gtviDo7U ZoZi2WI9LmFuaKuS2uWkB/h3BlnbwLS+vg== X-Google-Smtp-Source: ABdhPJw8ayzrX/E265uGhoGHV3RKbJptsAr6O5rJtDPEdb5TOgIwUKoBRFZVauOaMi94nUlCTTEq+Q== X-Received: by 2002:a05:620a:15c8:: with SMTP id o8mr16629358qkm.385.1637854086208; Thu, 25 Nov 2021 07:28:06 -0800 (PST) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id o126sm1583005qke.11.2021.11.25.07.28.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Nov 2021 07:28:06 -0800 (PST) Received: by mail-yb1-f180.google.com with SMTP id g17so12637038ybe.13; Thu, 25 Nov 2021 07:28:05 -0800 (PST) X-Received: by 2002:a25:38cf:: with SMTP id f198mr6864774yba.438.1637854085657; Thu, 25 Nov 2021 07:28:05 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202106300806.15U86pGq037942@gitrepo.freebsd.org> <20210706090311.aomxh4n45tkpktdc@aniel.nours.eu> <20211125142339.zxkjpbohkxk4hete@aniel.nours.eu> <9226a616-d279-9702-f13f-cee7299afc7a@FreeBSD.org> In-Reply-To: From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Thu, 25 Nov 2021 16:27:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 0a0f7486413c - main - man: Build manpages for all architectures To: Kyle Evans Cc: Andriy Gapon , Baptiste Daroussin , Ed Maste , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J0MG42fh1z4T8S X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Nov 25, 2021 at 4:15 PM Kyle Evans wrote: > > On Thu, Nov 25, 2021 at 8:30 AM Andriy Gapon 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. ---------- 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