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

[Alejandro Colomar]

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.

Regards,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature