bug-groff
[Top][All Lists]
Advanced

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

[bug #59425] [man, ms]: man pages are not compatibility-wrapper aware


From: Ingo Schwarze
Subject: [bug #59425] [man, ms]: man pages are not compatibility-wrapper aware
Date: Sat, 7 Nov 2020 05:37:33 -0500 (EST)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:82.0) Gecko/20100101 Firefox/82.0

Follow-up Comment #1, bug #59425 (project groff):

Changing the names of macro packages to avoid conflicts only makes sense as
long as you have a concept of portable macro packages *and* you desire
alternative implementations of standard macro packages to work with the same
roff implementation.  But none of that makes any sense in 2020.

Groff macro packages clearly cannot work with any other roff implementation,
and nobody in their right mind would want to use non-groff macro packages with
groff.  Alternative implementations of standard macro packages like man(7) and
ms(7) basically don't exist, at least not any that are meant to be portable
and that are relevant for practical use.

If you install multiple different implementations of roff, then the way to do
that is to have a different directory tree for each of them, including a
different macro directory for each one, and make sure every implementation
uses its own macro directory.

All this certainly isn't an issue at all for any of the *BSDs and never was
because BSD (singular, because only one BSD existed at the time, namely
4.4BSD) decided early on that groff (specifically, groff-1.08) is the system
roff, and it has been ever since, for about 27 years.

Touching this before release might cause a gratuitious risk of regressions,
but i think this obsolete "compatibility-wrapper" feature should probably be
deleted after release.  I doubt that it ever made much sense in the first
place.

On top of that, DragonFly is the only relevant BSD that still uses groff for
formatting manual pages, and it certainly doesn't support installing
alternative man(7) and ms(7) packages.  So this is a non-issue for more than
just a single reason.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59425>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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