Some groff man pages give incorrect path names to other documentation files. The path names are incorrect because these files are compressed on installation, and the man pages do not know this.
groff_mom(7) points to
pic(1) points to
It does not make sense to compress .mom and .ms files. Unlike man pages or other files one typically views via "man" or "less," which can uncompress on the fly, these files are meant to be processed by groff, which does not automatically uncompress input files. So making use of these examples requires intermediate files or a more convoluted command line.
Also, the space saved by compressing the files amounts to 112,918 bytes: a minuscule amount in, say, 1995, when hard drive sizes were measured in megabytes; an utterly unnoticeable amount in 2015. Anyone on a system where 110K of disk space matters won't install the documentation anyway.
Therefore, I believe the correct fix is to install the files uncompressed on the system, rather than changing the man pages to point to the compressed path. But one of these must be done to make the man page references correct.
(This bug was first brought up in bug 516732 comment 3. That bug dealt with another matter, so I am opening this new bug to track the problem of the erroneous path names.)
sorry, but i still don't see the point. most people don't care about this. the few that do can sort it out easily enough.
disk size arguments are not compelling. if they were, we wouldn't compress anything doc related in the first place.
the exact file name isn't really known either as the compression format is picked by the end user. we could change the docs so they have a glob:
but again, i don't see it being worth the time.
I still don't understand why there is controversy around whether documentation should be correct.
If it were somehow difficult to fix, I suppose a case could be made for leaving it wrong, but as you say, a trailing * at the end of the affected pathnames is all it takes. Then cut and paste will work.
Space issues aside, there should be logic behind choosing which file formats get compressed. This is why we have PORTAGE_COMPRESS_EXCLUDE_SUFFIXES. If .pdf is included in that list, why, logically, would .ps be excluded? These two formats serve essentially the same purpose and are often viewed using the same tools. What's the rationale for treating the two formats differently?
I understand this is a minor bug. Gentoo's Bugzilla has a "minor" severity level, which I chose for this bug. It could realistically be downgraded to "trivial." If bugs are going to be dismissed merely because they're minor or trivial, why are these severities offered as options? I am not expecting nor suggesting anyone put aside work on higher priority bugs to fix this.
(In reply to Dave Kemper from comment #2)
because nothing is free. the cost of maintaining sed scripts to rewrite docs to support a case where you assume the user is stupid is not worth the effort.