[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210731134821.qh5ol3wenvb73cjw@localhost.localdomain>
Date: Sat, 31 Jul 2021 23:48:23 +1000
From: "G. Branden Robinson" <g.branden.robinson@...il.com>
To: "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
Cc: Mickaël Salaün <mic@...ikod.net>,
Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Randy Dunlap <rdunlap@...radead.org>,
Vincent Dagonneau <vincent.dagonneau@....gouv.fr>,
landlock@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-man@...r.kernel.org, linux-security-module@...r.kernel.org,
Mickaël Salaün <mic@...ux.microsoft.com>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH v2 1/4] landlock.7: Add a new page to introduce Landlock
Hi, Alex,
[man, that CC list makes me cringe--this is all style issues and groff
release history, skip freely]
At 2021-07-31T12:51:30+0200, Alejandro Colomar (man-pages) wrote:
> Hi Branden, Mickaël,
> > One of the things I did after the groff 1.22.4 release (December
> > 2018) was to split groff_man(7) into two pages. The one you've
> > linked is the terser reference for seasoned (perhaps salty) man page
> > writers. Near the top of it you'll find this.
[...]
> Hmmmm, I can't find that text on my Debian Sid (with a bit of experimental)
> groff_man(7). Not even in the SEE ALSO.
That's because Debian is still shipping groff 1.22.4, even in unstable.
That's not shocking; I think Colin Watson was hesitant to ship a release
candidate and that was all the groff team had ready at the time. (I'm
the most active developer but not the project lead or release manager;
I've shied away from those responsibilities.)
> Re-reading this, we've been doing it wrong (as you pointed out in
> another thread) with macro names with variable part.
I do think it is wise to have a markup distinction between constant and
variable parts of C (or C preprocessor) symbol names. Admittedly, font
style distinctions can get lost in terminal copy-and-paste, but we can't
solve everything in plain text alone.
> I wasn't very convinced by the current usage of the man pages, but it
> was already current, so I just followed it :/
>
> I'll try to follow this from now.
The man-pages project has some style rules for visible output that are
not in alignment with what groff does, but the only one that comes to
mind is the style used for man page names (man-pages: bold; groff:
italics). I have a plan for resolving that on the rendering end[1].
> Ahh, I missed this text, as it was neither under .I nor .IR, and only
> had a fast read of the page. The 3rd paragraph hints that you should
> only use .IR when really needed, and use .I otherwise. But someone
> new to man-pages, who probably did never read this page (or read some
> specific paragraphs of it when needed), and found the extensive (and
> somewhat incorrect) usage of .IR in place of .I in the current man
> pages, might be confused by all of that inconsistency and hard-to-find
> (except by those who already know where it is (reference to Pirates of
> the Caribbean intended :) )) information.
Yes, it would really help if we (groff) could do a release. :-/
> > I'd appreciate feedback from anyone on how I can improve the above.
>
> I think it's great. But unless one reads the page with some time (and
> not only the bullets), one might think that the man page is
> incomplete. Maybe groff_man_style(7) is better suited for newbies,
> but I can't tell... I couldn't find it.
It's in groff Git and in the man-pages curated collection,
<https://man7.org/linux/man-pages/man7/groff_man_style.7.html>.
Michael apparently re-pulls from groff Git HEAD every time he does a
man-pages release, which makes the groff man pages massively more up to
date (by 2.5 years and counting) than what most distributions have.
> I'm not sure, but maybe (I always get confused by these things)?:
>
> [
> each _of the_ OverlayFS layers and merge hierarchies _is_ standalone and
> _contains_
> _its_ own set of files and directories,
> which is different from bind mounts.
> ]
>
> And still I'm not sure about the last "mounts".
Yes, I think that's an improvement, and "bind mounts" could be made
singular: "a bind mount".
Regards,
Branden
[1] https://lists.gnu.org/archive/html/groff/2020-08/msg00068.html
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists