FS#16807 - [groff] Replace groff in core by mdocml

Attached to Project: Arch Linux
Opened by Ilya Ilembitov (ilembitov) - Friday, 23 October 2009, 18:00 GMT
Last edited by Allan McRae (Allan) - Saturday, 28 April 2012, 12:41 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Paul Mattal (paul)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Basically, I just wanted to propose to replace groff with mdocml.

Groff, as a troff implementation is mostly used as a way to get man pages these days, and few people really use it as a word processing/desktop publishing solution (although, me, personally, would love to see the revival of troff in these areas - but we aren't likely to see this happening within the current groff project, in my opinion). Which means, that not many people actually need the support for me/mm/ms/mom/etc macros out of the box, they just need something fully compatible with man pages format. As far as I understand, this is the reason why groff in Ubuntu/Debian world, for example, got split into two packages, the first (groff-base) containing only the man macro set, the the second (groff) being a full set. But there is also a second point: as far as I can judge, groff packages are actually tough to maintain. Basically, this is the reason why many distros are often reluctant to update or deal in other way with them.

So this is why mdocml could be a nice idea:

http://mdocml.bsd.lv/

Basically, this is a pretty recent implementation of the man macro set of groff, capable of producing the actual ASCII pages as well as the HTML output (to be published online, for instance, or used by a graphical man pages viewer). The biggest point here is that mdocml is written from scratch and doesn't rely on groff code base, thus it should actually be cleaner (and we all know the perfectionist-at-all-costs approach to code, shared by BSD people). It's written in C (and not in C++) and drops support for other macros, so it's fast and tiny. It is actively used within the OpenBSD/NetBSD community, so it actually has a lot of activity. And it's claimed to run on Linux as well.

So, my point for this change (which is, use mdocml in core and push groff to /extra or even /community):
-save some space in iso files and base installations. I believe, most of Arch users would love to see another improvement here
-save some efforts on supporting the package (yes, I know that this is originally a BSD package, but I believe this is not the first time Arch gets a BSD package in core set - for instance, libfetch also comes from BSD, although it is used by pacman).
-switch to a more lightweight and modern solution
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 28 April 2012, 12:41 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See final comment
Comment by Eduardo Lopes (duca) - Saturday, 23 January 2010, 04:31 GMT
Has anyone tested this alternative already?? I like the idea of make groff an alternative to something more lightweigth instead. I will only be able to test this solution on sunday.
Comment by Paul Mattal (paul) - Saturday, 06 March 2010, 20:14 GMT
Has anyone tested this yet with success?

If not, I plan to close this on April 2010 bug day as "won't implement", since it will then have been open for 6 months without activity.
Comment by Robert (theapodan) - Wednesday, 17 March 2010, 00:47 GMT
I used groff to typeset papers and such in college, and would still want groff.

It seems that it would increase, rather than decrease, complexity to maintain both groff and this mdocml, when groff alone has been and continues to be sufficient, and there don't seem to be any truly compelling reasons to stop using it; I've never seen anyone complain about the long wait to display manpages.
Comment by Eduardo Lopes (duca) - Thursday, 18 March 2010, 06:06 GMT
I 'm giving it a try, but it showed some problems i am trying to fix along with the author.
Comment by Eduardo Lopes (duca) - Thursday, 18 March 2010, 06:09 GMT
Just to give as comparison:

source compressed: groff: 4,5mb, mdocml: 150kB
installation: groff ~20mb, mdocml: 260kB

Aiming to build as system as small as possible, changing to mdocml would be a nice move.

As soon as i manage to solve the issue, i'll bring some comments about it's performance.


EDIT: Corrected the really messed phrase i wrote
Comment by Thomas Dziedzic (tomd123) - Thursday, 03 June 2010, 22:54 GMT
is there any progress? has the "issue" been fixed?
Comment by Eduardo Lopes (duca) - Tuesday, 08 June 2010, 11:45 GMT
This is an old email i received, i did not find anything really usefull in the netbsd list as sugested, but i believe i was unlucky with the keywords so far.

From the author:
the man and mandoc utilities are not related: all mandoc does is transform -man or -mdoc input pages into formatted output, while man is responsible for finding formatted pages and displaying them with the pager. These are completely separate issues.

If you want advice on how to integrate mandoc system-wide as a replacement for groff, you may want to search/ask on the NetBSD mailing lists, as they did considerable work in doing so.

Note, significantly, that the -man support in mandoc isn't excellent: the utility's main focus is -mdoc pages. From what I understand, arch only redistributes existing "core" utility manuals (such as for GNU cat, ls, etc.) as part of the base system. These are mostly (all?) in -man, which will cause problems. Integration is much easier on BSD systems because (1) the manuals are all self-contained in the operating system, and thus may be changed and repaired; and (2) are all in -mdoc.

I hope I was able to shed some light on the situation.

Take care,

Kristaps
Comment by Karol Błażewicz (karol) - Tuesday, 22 June 2010, 15:51 GMT
I have mdocml on one of my boxes and in the past weeks I've used it extensively to learn about all the fine programs I've got on my system (what does 'rev' do?). Great many of mdocml-formated man pages are mangled beyond use; whether it's a problem w/ the wrong markup or mdocml - I can't tell but it's a show-stopper for me.
The pages render fine w/ the default man-db + groff setup.
Comment by Natanael Copa (ncopa) - Tuesday, 06 July 2010, 14:03 GMT
I have tested mdocml on Alpine Linux and for me the main issue seems to be the /usr/bin/tbl utility which is still provided by groff. There is http://tbl.bsd.lv/ but this seems to work a bit different than groff's tbl.

When running 'tbl /usr/share/man/man3/fopen.3' I get:
/usr/share/man/man3/fopen.3:1:1: bad syntax

Comment by Michael Witten (mfwitten) - Thursday, 14 October 2010, 03:25 GMT
mdocml's site (http://mdocml.bsd.lv/) says it all: "The mission of mdocml is to deprecate groff, the GNU troff implementation, for displaying -mdoc pages whilst providing token support for -man."

You'll get `token support' for `-man'.
Comment by Eduardo Lopes (duca) - Thursday, 14 October 2010, 19:52 GMT
The main dev. said to me that freebsd has deprecated groff to man7 stuff, but the info on implementing it was buried in one of their maillists
Comment by Allan McRae (Allan) - Thursday, 17 March 2011, 13:50 GMT
mdocml has now completely replaced groff in OpenBSD:

http://undeadly.org/cgi?action=article&sid=20110314142734

and the latest version appears to fix many of the issues pointed out here. I would really like to see someone go through all packages in [core] and make a report of the compatibility of this with their man pages. Then we would have an accurate picture of what needed done to switch to this allowing us to make a final decision.

However, given the main advantage here is install size, I'm not sure it is worth the effort, especially when we are talking about 20MB installed. If you were trying for a system with minimal space, then you probably would remove this package anyway...
Comment by Karol Błażewicz (karol) - Thursday, 17 March 2011, 14:09 GMT
@Allan
If by "latest version' you mean 1.10.9 https://aur.archlinux.org/packages.php?ID=41433 then I'm afraid it's a -1 from me (or maybe I can't use it properly). Rendering man page for find shows that .e.g the 'Examples' section renders in a wrong way i.e. many (but not all) examples spread across many lines

EXAMPLES
find
/tmp
-name
core
-type
f
-print
|
xargs
/bin/rm
-f

instead of

EXAMPLES
find /tmp -name core -type f -print | xargs /bin/rm -f

It may be possible to fix this, but I haven't really tried,
I use
man1 () { zcat $(find /usr/share/man/ -iname "$1".?.gz -o -iname "$1".??.gz) | mandoc | less; }
Comment by Thomas Dziedzic (tomd123) - Sunday, 08 May 2011, 15:13 GMT
Decision? this has been open for mare then a year.. if it's worth anything -1 from me
Comment by Karol Błażewicz (karol) - Sunday, 08 May 2011, 15:16 GMT
As much as I would like, it simply doesn't work well enough to bother atm.
-1 from me (user signoff ;P)
Comment by Greg (dolby) - Sunday, 08 May 2011, 17:09 GMT
While browsing one upstream projects devel source tree i bumped into groff mentioned as a makedependency, at least from the source tree, not sure about releases and i dont remember the project. Are we sure groff isnt a makedependency for any stuff in Arch? If it is -1 from me as well. Even if that means we get to keep a 20mb c++ monster just for viewing man pages than having both in Arch. +1 for closing this as wont implement.
Comment by Thomas Dziedzic (tomd123) - Sunday, 08 May 2011, 17:33 GMT
groff is a makedepends for libldap:
grep -r groff /var/abs/
...
/var/abs/core/libldap/PKGBUILD:makedepends=('tcp_wrappers' 'groff')
Comment by Karol Błażewicz (karol) - Friday, 29 July 2011, 01:39 GMT
I just wanted to say that the latest version - 1.11.5 - produces a much more faithful output (i.e. more similar to man-db).
Comment by Allan McRae (Allan) - Saturday, 28 April 2012, 12:41 GMT
Old bug is old... Going to close as "Won't Implement".

If this is ever going to be implemented, someone will have to do a re-assessment to see if there are still issues and provide a better reason other than size to replace this.

Loading...