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

[Ingo Schwarze]

Hi Alejandro,

Alejandro Colomar wrote on Sun, Jun 19, 2022 at 05:15:54PM +0200:

> 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).

And you expect Debian package managers will actually do that?
Declare alternative dependencies on specific versions of groff
and mandoc because an upstream developer chose to use the .MR
macro in upstream manual pages?

Here are a few traps making it unlikely to work in practice:

 1. Most likely, the upstream developer found .MR in groff_man(7)
    and just used it, not even noticing there are potential
    portability concerns, or judging those unlikely to cause
    real harm.

 2. Upstream likely didn't document the requirement in the
    installation notes - because who understands manual page
    markup portability requirements and documents them?

 3. The packager likely doesn't notice.  Which packager re-reads
    the entire text of the documentation of their package for
    every update to make sure there are no compatibility issues?

 4. Even if the packager notices the problem, they are unlikely
    to correctly pinpoint the dependency bacause which packager
    is experienced with investigating markup compatibility
    requirements?

Even if none of these traps strike and the packager writes a
correct dependency rule, that is unlikely to actually help.
Either the required version of groff or mandoc is already packaged
for the given version of Debian, in which case the dependency isn't
needed at all because everything already works by default.
Or that version is not yet packaged for that version, in which
case something is going to fail hard sooner or later, possibly
both at package build time and at package installation time.

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

For most systems, i expect the same as described above for Debian:
either packages of the required version are available, in which
case everything works by default, or no such packages are
available yet, in which case declaring dependencies won't help.

For systems that don't even make groff or mandoc avaialble as
official packages but where users rely on unofficial package
management systems, the situation may be even worse.  For example,
MacOS, Oracle Solaris, and the like come to mind.

> 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.

Don't hold your breath, it would be a pity to lose you!
What was it again that MacOS currently ships in the base system?
Was it groff-1.19?  Or did Apple update base groff lately?

> 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),

I wouldn't bet on that.  My top candidates for trouble would include
systems like Oracle Solaris, IBM AIX, HP-UX, and others that i fail
to think of right now.  Debian probably is among the slower-moving
widely-used *Linux* distributions, but i'm not convinced it is
among the slowest moving OSes.

> 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.

You may have to wait long...

Do you really want to wait 15 years or more for something that can
likely be implemented in a less disruptive manner?

Yours,
  Ingo