Hi, are there any other users who have /usr/local or /usr/local/man as a symlink or mounted via amd(8)? Note that i do NOT recommend such very unusual configurations at all, they have caused trouble in the past, i'm merely asking for testing purposes. If you use such a configuration, please update your mandoc such that you have OpenBSD: mandocdb.c,v 1.215 (or later) (by installing a snapshot dated at least a full day after 2020/01/26 21:24:58 UTC or by compiling from source and installing in /usr/src/usr.bin/mandoc/) and try whether after installing packages that contain symlinks in manual page directories, man(1) works as expected on such manual pages even *without* running makewhatis(8) manually and *without* running weekly(8). And of course, watch out whether you see any regressions.
It turned out the filescan() function in mandocdb.c is well suited as a habitat for worms, and if i have disturbed any of them with the commit below, i'd prefer appeasing them again ASAP, well before we approach release. Here are a few examples of manual pages that are good for testing: package manual page vim rgvim # as opposed to vim(1) itself python-2.7 python2 # as opposed to python2.7(1) openldap-client ldap_init # as opposed to ldap_open(3) texlive_texmf-minimal pdflatex # as opposed to pdftex(1) The following command may give you more examples of pages for testing on your system: $ find /usr/local/man -type l Please make sure that *after* updating mandoc, you pkg_delete(1) the package(s) in question and then pkg_add(1) them anew, and only test man(1) after that. Please report any cases where pages aren't found as expected, report any messages similar to man: outdated mandoc.db lacks rgvim(1) entry, run makewhatis /usr/local/man you may encounter, and report any other regressions. Always include output from "man -w" for the pages you are trying to read, in addition to describing your findings. In case any of this screws up your system, running makewhatis(8) manually without any arguments will almost certainly fix it (but please report first). Do not attempt to downgrade again in the unlikely case that testing reveals issues; that would be more likely to make matters worse rather than help. Finally, note that nothing is wrong in pkg_add(1), the issues were in makewhatis(8) only. Thanks, Ingo CVSROOT: /cvs Module name: src Changes by: [email protected] 2020/01/26 14:24:58 Modified files: usr.bin/mandoc : mandocdb.c Log message: Repair more of the issues that i found in filescan() while investigating the report from <Andreas dot Kahari at abc dot se> on ports@: For a symlink, use the first of the following names that is available: 1. In -t mode, the symlink itself (unchanged). 2. When the (unresolved) symlink already resides inside the manpath, just strip the manpath and use the rest (unchanged). 3. When prefix(es) of the unresolved symlink point to the manpath, strip the longest such prefix and use the rest (new); this fixes situations where the manpath or one of its parent directories is a symlink and at the same time contains symlinks to manual pages. 4. Fall back to the fully resolved symlink, with the manpath stripped (new); this may for example happen when the command line passes symlinks from outside the manpath that point to manual pages inside the manpath, or if manual page trees contain symlinks to symlinks and not all of them are given on the command line. The fallback (4) isn't perfect. You can construct symlink spaghetti in such a way that this algorithm will not enter all manual page names into the database that a human would be able to deduce. But i do not expect such spaghetti to actually occur in practice (not even in ports), and a full fix would require re-implementing realpath(3) in terms of step-by-step readlink(2) calls, repeating the complicated algorithm (3) after each step. While here, also stop using PATH_MAX as the size of a static buffer in filescan(); on some systems, it can be unreasonably large. Instead, allocate path strings dynamically.
