On Feb 23, 2013, at 8:53 PM, Ken Moffat wrote:
But I think that the savings from stripping files are considerably greater, and I'm unconvinced that .xz *de*compression is particularly fast (from memory, sitting waiting for a manpage to render can be extremely annoying).
Why was compressdoc included to begin with? I ran man <manpagehere> between gzip or xz compresed files and noticed no difference (humanly) between opening of the files. A render isn't done, it's a decompression. If the idea is of space, then remove the stripping of debugging symbols from the book as well. The issue isn't space. Let me let you in on a secret. People are using LFS for embedded systems which don't use 2 TB drives. I'm telling you that using xz the compression is great and the decompression is rate is little. Also, maintenance doesn't mean broken, it means keeping it operational. Optimization is to keep it running pristine.
The script has bzip2 and gzip support. I'm adding xz support. No need for 1000 lines of poems stating why it shouldn't be added. If you don't want to add it, remove compressdoc permanently, or don't add my additions. Doesn't matter. What is going on in here has nothing to do with my original post:
"This is a rough draft but any input is greatly appreciated to fix any errors."In which none have fixed errors if they are there, only attacked the issue that the script has been updated. If I wanted to fix the book I'd post to blfs-dev.
Sincerely, William Harrington
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
