| 1 |
On 01/10/2017 06:54 AM, Jan Stary wrote: |
| 2 |
> |
| 3 |
> These are workarounds. Let me get back to the original question: |
| 4 |
> would you please consider having _uncompressed_ manpages as the default? |
| 5 |
> |
| 6 |
> On this particular system, the bzipped /usr/share/man/ is 67M. |
| 7 |
> The uncompressed man/ is 108M. That's 40M saved. Seriously? |
| 8 |
|
| 9 |
Since everyone else is giving you a hard time, I think compressing all |
| 10 |
of the documentation by default is annoying and over-complicates things. |
| 11 |
|
| 12 |
However, if you asked me what *could* be compressed by default, man |
| 13 |
pages with their separate /usr/share/man directory and doman helper |
| 14 |
would be at the top of the list. They aren't meant to be read by humans, |
| 15 |
the default reader handles them, and they compress well. |
| 16 |
|
| 17 |
And in direct contradiction to my last paragraph, we did invent dohtml |
| 18 |
and now have PORTAGE_COMPRESS_EXCLUDE_SUFFIXES set to work around this |
| 19 |
exact problem, that web browsers won't call bunzip2 in a pipeline. It |
| 20 |
seems a little unfair to let web browsers off the hook but not mdocml. |
| 21 |
|
| 22 |
There are probably fewer people who care about the space than there are |
| 23 |
users who have been annoyed that they can't run an example because |
| 24 |
ruby/php/python won't run a compressed script. I know that we have |
| 25 |
"docompress", but inside the ebuild is the wrong place to battle an |
| 26 |
implementation-specific default setting. |
Archives