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
