On Sun, Oct 4, 2026 at 3:27 AM Max Nikulin <[email protected]> wrote: > > On 28/09/2026 9:22 pm, Vincent Lefevre wrote: > > On 2026-09-28 16:05:55 +0200, Vincent Lefevre wrote: > >> The (updated) original version is here: > >> > >> https://man7.org/linux/man-pages/man8/nscd.8.html > >> > >> But it does not say either which distribution it is. > > > > This actually comes from the official Linux man pages... and > > I completely forgot that GNU is against man pages. It explains why > getent(1) was not updated when a new option had been added. However nscd > is not mentioned in glibc-doc-reference texinfo docs.
I would not say "against man pages." Rather, I would say, the info pages are authoritative and the man pages are optional. From the GNU Coding Standards, <https://www.gnu.org/prep/standards/standards.html#Man-Pages>: In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. It’s your choice whether to include a man page in your program. When you make this decision, consider that supporting a man page requires continual effort each time the program is changed. The time you spend on the man page is time taken away from more useful work. For a simple program which changes little, updating the man page may be a small job. Then there is little reason not to include a man page, if you have one. For a large program that changes a great deal, updating a man page may be a substantial burden. If a user offers to donate a man page, you may find this gift costly to accept. It may be better to refuse the man page unless the same person agrees to take full responsibility for maintaining it—so that you can wash your hands of it entirely. If this volunteer later ceases to do the job, then don’t feel obliged to pick it up yourself; it may be better to withdraw the man page from the distribution until someone else agrees to update it. When a program changes only a little, you may feel that the discrepancies are small enough that the man page remains useful without updating. If so, put a prominent note near the beginning of the man page stating that you don’t maintain it and that the Texinfo manual is more authoritative. The note should say how to access the Texinfo documentation. Be sure that man pages include a copyright statement and free license. The simple all-permissive license is appropriate for simple man pages (see License Notices for Other Files in Information for GNU Maintainers). For long man pages, with enough explanation and documentation that they can be considered true manuals, use the GFDL (see License for Manuals). Finally, the GNU help2man program (https://www.gnu.org/software/help2man/) is one way to automate generation of a man page, in this case from --help output. This is sufficient in many cases. > Notice that in #34668 you complain concerning man pages that actually > are maintained by a separate project. It may be annoying to glibc > developers. > > This bug report indirectly says that users expect to find man pages that > may be more convenient than info manuals. On the other hand, it is for > those who defines GNU&FSF policies. Glibc developers just follow imposed > rules. It is better to ask for actions that may be performed by project > developers, e.g. to add .texi docs. > > > the issue is in Debian, which apparently comes from BSD. In > > bookworm: > > > > NSCD(8) BSD System Manager's Manual > > NSCD(8) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > https://manpages.debian.org/bookworm/nscd/nscd.8.en.html > I see no "BSD": > "NSCD(8) System Manager's Manual NSCD(8)" > > The "BSD" has been removed in trixie, but the man page remains > > the same one from 2001. The description in the above man page > > is more detailed (though still incomplete). I've reported a bug. > > Debian maintainers added files to debian/local/manpages in glibc. Jeff
