[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: man(7) .TH font change, was: groff man(7) `B` macro...

From: Alejandro Colomar
Subject: Re: man(7) .TH font change, was: groff man(7) `B` macro...
Date: Sun, 19 Jun 2022 17:15:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 6/19/22 17:00, Ingo Schwarze wrote:> All that groff_man(7) currently> tells them is> > History> [...]> The plan9port project's troff introduced .MR in 2020.

So what are they supposed to say?  "Formatting our documentation
requires plan9port troff from 2020 or later, groff 1.23.0 or later, or
mandoc 1.14.7 or later and will not work with other implementations of
the man(7) language"?  That would require doing some serious research
on their part, and i expect that most programmers, even experienced
and competent ones, do not have the required domain knowledge about
manual page markup to correctly research and explain such a requirement.
And even when stated correctly, such a statement would be highly
cumbersome and eventually become incomplete and outdated.

Even if such an unsusual statement would be made, what the hell
is the packager supposed to do with it?  They have no idea whether
the end-users they are making their packages for will choose to
install man-db+groff or mandoc when these options exist.
The packager for some random piece of software likely has no control
over which version of groff or mandoc other packagers may package
for the same operating system.  And what are they supposed to do
if their system uses a completely different man(1) and *roff(1)
implementation in the first place?

I can only talk about Debian/apt-get(1), which is the one I use.

It has a very clear way to declare alternative dependencies, and to declare a minimum version for each dependency (and build dependencies, but that's irrelevant in this case).

For other systems, I completely ignore how hard it is to declare such deps.

At the end of the day, there isn't much they can do in *any*
case, and the statement "Formatting our documentation requires..."
will likely be completely ignored by most packagers, all the more so
as this will usually *not* result in build-time problems that become
apparent to the packager, which means end-users will see random
gaps in manual pages without having the slightest idea why, without
having any diagnostic tools at hand, nor any of the skills needed
to fix such issues.  And even if they knew what was going on, what
*should* an end-user do?  Manually ditch the packaged version of groff
or mandoc installed on their computer and compile a newer version
from source?  That's completely unrealistic and would seriously annoy
even highly capable, technically-minded people.

Debian is one of the slowest moving OSes. I expect that when Debian has groff-1.23.0, most other OSes will also have it. I'd still check to see how's the rest of the world doing, before breaking them so hard, of course.

The biggest issue would be users of old systems (e.g., Debian oldstable), that may work from their system on the man-pages repo. For that case, I considered waiting for oldstable (or even oldoldstable) instead of stable. Again, it's just a matter of time, I think. When .MR has been in the game for at least 15 years, we can consider that absolutely no user will have a system that lacks it. It's all a balance about how many years to wait.



Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]