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.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 3725 invoked from network); 18 Aug 2021 22:02:19 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 18 Aug 2021 22:02:19 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id c1030b0a for ; Wed, 18 Aug 2021 17:02:18 -0500 (EST) Received: from mail1.systemli.org (mail1.systemli.org [212.103.72.247]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 8394ae34 for ; Wed, 18 Aug 2021 17:02:17 -0500 (EST) Subject: Re: makewhatis: segfault in dbadd when using -a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=systemli.org; s=default; t=1629324135; bh=DI1jfzN4xNt8Y19tc4/SnFFJImxZbWaMiCU3tof1L34=; h=Subject:To:References:From:Date:In-Reply-To:From; b=G4YZIuljwjVBsUIpRpaAzWFqHANV0wlDInbD5jmlDmo7Ug6ZsrXxaO1ShI0UPLnbN ZWmoEDamMrgzhF65EnEj8EHEs5XlCYtEOSrivfC07KINEhZWdg0l6Yfm9SmeNcS/vB j43Q7sDsXyMHKM2x0VpiNmrCfv2uN7loaMT/e4WGq9HjyJ6sCjer1JJce3jldU+PEe kj2wzeNbToG/N0Kdxnbf2fz5zPkONUsa/Pmz5DyXfW0PG8zNMCXVAYhmUlXNb1zZJx ZTUQXOpGI00DmCYupF91NHmuRG8P7pipDi91oDD63iIQgKvG0NZT5Auuhz3LHYSUOG LH3hEepAqW04g== To: tech@mandoc.bsd.lv References: <20210811150959.GI38774@athene.usta.de> From: sternenseemann Message-ID: <14853b5f-c67e-a317-17fe-9c3a92f516b7@systemli.org> Date: Thu, 19 Aug 2021 00:02:13 +0200 X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 In-Reply-To: <20210811150959.GI38774@athene.usta.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Hi Ingo, 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. > You stared at the wrong place. That may be where the car finally > exploded, but not where it ran off the road. Indeed, I later realized that treescan was to blame when I investigated something else which you won't like to hear… > Note that i don't feel like actually *following* such a link unless > people show real-world use cases that require it. If the link target > is below the same manpath, it will be reached by direct traversal, too. > Nobody claimed so far that having such a link point to the cellar or > store might be useful, and if i understand sufficiently well what the > point of a cellar or a store is, indeed it could hardly be useful. > If it points somewhere else, it certainly should not be followed. So, about that: NixOS creates its man directories exclusively by symlinking man pages into a common directory from a lot of sysroot-esque directories in the store. Of course the starting point is not individual man pages, but lots of share/man directories in the “little sysroots”. When building the common man path, naturally the script tasked with doing this tries to create as little symlinks as possible: 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. 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) and you'd be hesitant to touch the in-tree one for something like this?! Cheers, Lukas -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv