From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9435 invoked from network); 19 Aug 2021 17:12:00 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 19 Aug 2021 17:12:00 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 8d24ed54 for ; Thu, 19 Aug 2021 12:11:56 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 8c5cbe6d for ; Thu, 19 Aug 2021 12:11:53 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1mGla3-0004bn-K4; Thu, 19 Aug 2021 19:11:52 +0200 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1mGla2-00009N-GQ; Thu, 19 Aug 2021 19:11:50 +0200 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1mGla2-0006k5-Am; Thu, 19 Aug 2021 19:11:50 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 3db61eca; Thu, 19 Aug 2021 19:11:50 +0200 (CEST) Date: Thu, 19 Aug 2021 19:11:50 +0200 From: Ingo Schwarze To: sternenseemann@systemli.org Cc: tech@mandoc.bsd.lv Subject: Re: makewhatis: segfault in dbadd when using -a Message-ID: <20210819171150.GD56790@athene.usta.de> References: <20210811150959.GI38774@athene.usta.de> <14853b5f-c67e-a317-17fe-9c3a92f516b7@systemli.org> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14853b5f-c67e-a317-17fe-9c3a92f516b7@systemli.org> User-Agent: Mutt/1.12.2 (2019-09-21) Hi Lukas, sternenseemann wrote on Thu, Aug 19, 2021 at 12:02:13AM +0200: > On 8/11/21 5:09 PM, Ingo Schwarze wrote: >> Does the following patch make sense to you and work for you? > Yes, tested it with my real world case and it doesn't crash anymore! > Sorry for the delay with testing. No problem, thanks for testing. The patch is now committed to OpenBSD-current and to bsd.lv HEAD. > If a directory of the common manpath is only present in one > store-sysroot, the script will symlink the directory instead > of creating one and symlinking every file in it. > > Unfortunately, there is a few man sections which basically come > exclusively from one package, so from one store path: man1p and man3p > from Linux' man-pages-posix package. So for me > $GLOBAL_MANPATH/share/man3p is a symlink to > /nix/store/2fn4bf6xj9bxq3dpa6mznqbzqqanfdiv-man-pages-posix-2017a/share/man/man3p > and makewhatis(8) can't index it. Uh oh. So there *is* a real-world use case for symlinks to directories. It doesn't matter that on first sight, this whole approach feels quite fragile to me. Isn't that going to blow up in horrible ways as soon as somebody creates a package that also uses "man3p"? For example, on OpenBSD, "man3p" is used for manuals of Perl library functions. schwarze@isnote $ uname -a OpenBSD isnote.usta.de 6.9 GENERIC.MP#101 amd64 schwarze@isnote $ man -f 3p warnings encoding::warnings(3p) - Warn on implicit encoding conversions warnings(3p) - Perl pragma to control optional warnings warnings::register(3p) - warnings import function Anyway, if systems use that, considering whether it can be supported with resonable effort makes sense. No guarantee, of course. I'll think about it for a bit. > This is, however, a bit of an edge case and there is a workaround > (running a script which converts it into a proper directory), but still > a bit annoying. For the standard man sections this will probably never > happen. > > I also fear that traversing such symlinks is not easy to patch into the > portable version since it would mean changing treescan quite > significantly (which currently assumes that symlinks if they are "good" > point to regular files) Yes. > and you'd be hesitant to touch the in-tree one > for something like this?! Can't say without looking at the code in detail, so bear with me. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv