On 8/1/22 00:55, Ingo Schwarze wrote:
Yes, distributors that incorporate packages with man pages using the new
`MR` macro, racing ahead of those same distributors' update of groff
1.23.0 (whenever that happens), run the risk of some unhappy man page
readers.
As i explained earlier, people doing packaging will rarely be
aware what the technical requirements for formatting any given
manual page are, and when i watch packagers, i don't usually see
them scrutinizing manual pages for good formatting. And again, the
choice of using .MR will not be made by *any* packager, but by the
upstream project. So the packages would only have the choice to
delay the package update, waiting for a typically *different*
packager to update groff. It is not clear delaying a software
update for such a reason is even a good idea.
I usually consider it bad practice for upstream developers to make use
of features not yet released, or not yet packaged to mainstream distros.
It's not nice to tell someone building your source that they also need
to build the dependencies from source (I've seen some projects that
require building LLVM from source to be able to build their program; of
course I'm not building LLVM from source just to build a random program).
IMO, dependencies should always be used from the system, and should be
stated clearly (including versions if necessary) somewhere. That's part
of why I think providing an upstream package is good: it forces you to
specify Build-Depends.
I don't think any upstream project should use a feature that's not
released at least in a distro, and preferably in a reasonable set
(Debian unstable, Fedora, Arch, OpenSUSE Tumbleweed).
Only for experimental features that are not intended to be used by most
users or even contributors, can one use an unreleased feature (as I did
for example with some subtargets of the `make lint` target; I don't
expect it to be run by anyone other than me for now).
So, if upstream programmers follow some basic common-sense rules,
packagers shouldn't even have to look at these problems.
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
