[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #65702] tmac/doc.tmac: compatibility mode not restored at end
From: |
G. Branden Robinson |
Subject: |
[bug #65702] tmac/doc.tmac: compatibility mode not restored at end |
Date: |
Tue, 7 May 2024 07:06:39 -0400 (EDT) |
Update of bug #65702 (group groff):
Severity: 3 - Normal => 2 - Minor
Item Group: Incorrect behaviour => Lint
_______________________________________________________
Follow-up Comment #3:
Ah, it's a theoretical concern.
1. _groff_ is not _in general_ installed with compatibility mode on by
default, not on any system.
2. What _does_ happen is that, _if_ "compatibility wrappers" are generated
for certain macro packages, those wrappers get a "cp 1" request injected into
them.
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n301
See in particular line 311. The logic is fairly old.
https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/Makefile.sub?h=1.22.3.real#n137
These wrappers came in via a contribution from Peter Bray in 2015.
https://git.savannah.gnu.org/cgit/groff.git/tree/ChangeLog.122?h=1.23.0#n2103
...to address bug #44784.
3. The list of macro packages for which compatibility wrappers may be
generated is dynamically generated (by looking in the system troff's "tmac" or
"macros" directory for files _without_ an FSF copyright notice). In practice,
this tends to include "an", "m", and "s".
4. "doc" (mdoc) is not in that list.
5. Solaris 10 evidently never bothered picking up the package from
4.3BSD-Reno or later. Makes sense, as by the time of that BSD release, AT&T
had an investment stake in Sun and was steering it to a System V base.
So this doesn't really matter much. Demoting to "minor", "lint".
If it ever causes a problem on an actual system, it can be re-promoted.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65702>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/