groff
[Top][All Lists]
Advanced

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

Re: the compatibility of man(7) (was: man(7) .TH font change, was: groff


From: Alejandro Colomar (man-pages)
Subject: Re: the compatibility of man(7) (was: man(7) .TH font change, was: groff man(7) `B` macro...)
Date: Mon, 1 Aug 2022 01:22:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.0



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/



reply via email to

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