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

Group

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

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

Please enter the title of George Orwell's famous dystopian book (it's a date):

Follow 4 latest changes.

Date	Changed by	Updated Field	Previous Value	Replaced by
2022-08-19	barx	Carbon-Copy	Removed 93119	-
2020-11-11	gbranden	Status	Need Info	Postponed
		Assigned to	None	gbranden
		Summary	[man, ms]: man pages are not compatibility-wrapper aware	[man, ms, mm]: drop compatibility wrapper feature

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

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

<a href="#postcomment">Post a Comment</a>

<a href="#discussion">Discussion</a>

<a href="#attached">Attached Files</a>

<a href="#dependencies">Dependencies</a>

<a href="#cc">Mail Notification Carbon-Copy List</a>

<a href="#votes">Votes</a>

<a href="#history">History</a>