bugGNU roff - Bugs: bug #59425, [man, ms, mm]: drop compatibility...

 
 

bug #59425: [man, ms, mm]: drop compatibility wrapper feature

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sat 07 Nov 2020 06:08:37 AM UTC
   
 
Category:  Macro package - others/general Severity:  3 - Normal
Item Group:  Documentation Status:  Postponed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 10 Aug 2023 02:03:29 PM UTC, comment #5: 

Postponing (keeping postponed) at least until Solaris 10 really does hit end-of-life, now kicked by Oracle into 2025.

G. Branden Robinson <gbranden>
Group administrator
Fri 19 Aug 2022 07:49:37 AM UTC, comment #4: 

comment #3:

> Re: comment  #2
> > Maybe we should make an official list of [things to retire soon].
>
> Sure, if you want to.  That can do no harm, even if it turns out to not be complete.


Gave this its own ticket, bug #62916.

Dave <barx>
Group Member
Wed 11 Nov 2020 12:27:09 PM UTC, comment #3: 

Re: comment  #2

>> nobody in their right mind would want to use non-groff macro packages with groff.


> In principle, they should work find in compatibility mode.


The question is not so much whether they would work but why anybody would want to do that.  Groff has its own man, ms, and mm implementations and they are compatible.  The historical implementations have severe limitations and provide no benefit i can see.

> Maybe we should make an official list of [things to retire soon].


Sure, if you want to.  That can do no harm, even if it turns out to not be complete.

Ingo Schwarze <schwarze>
Group Member
Wed 11 Nov 2020 09:11:59 AM UTC, comment #2: 


comment #1:

> 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.


[raises hand]  I'd be curious to see what happened.  In principle, they should work find in compatibility mode.

>  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.


You mean alternatives to both AT&T's and groff's?

Yeah, I don't know of any.
 

> 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.


Yes, that's what I do with Heirloom.

> 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.


Agreed; I don't plan to do anything about it right now, apart from fix the man pages, maybe.

> 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.


Yes, I think this can go on the list of things to retire after 1.23.0.  Maybe we should make an official list of these, and include it in the release notes so people have as much warning as possible.  ("If you use this stuff, speak up now.")

Kind of on that note, glilypond has been totally broken for 5 years, near as I can tell.  Though I'd rather it be fixed than dropped.  Embedding a chunk of score in a document is something I am actually personally inclined to do.

G. Branden Robinson <gbranden>
Group administrator
Sat 07 Nov 2020 10:37:33 AM UTC, comment #1: 

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.

Ingo Schwarze <schwarze>
Group Member
Sat 07 Nov 2020 06:08:37 AM UTC, original submission:  

Evidently it doesn't confuse many people, or the macro package compatibility-wrapper feature is little-used (or both), but our man pages for man and ms are technically wrong because they don't refer to their implementations with the wrapper prefix.

See Makefile.am:247-277.  Also lines 917-920 for where the actual substitutions take place.

The mm package already does this correctly, so it should be pretty easy to ape.

I'm a bit curious why this hasn't been done for mdoc.  Don't the BSDs still have their own mdoc macro package (upon which ours was originally based but then heavily groffified), or do they rely exclusively on mandoc/mdocml for their mdoc rendering needs these days?

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-08-19 barx Carbon-CopyRemoved 93119 -
    2020-11-11 gbranden StatusNeed Info Postponed
        Assigned toNone gbranden
        Summary[man, ms]: man pages are not compatibility-wrapper aware [man, ms, mm]: drop compatibility wrapper feature

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code