[PATCH] add lzma and xz to unpack plugin

[Zbigniew Luszpinski]

> Zbigniew Luszpinski wrote:
> > Hello,
> > 
> > many sites use lzma and xz for keeping files small to save on bandwidth cost.
> > This is important for open source, freeware sites to keep costs low so please
> > patch lunar tarball with this patch. For us this will be faster downloads.
> > For me applying this patch will make developer work easier: I will not have
> > to backport module updates anymore.
> 
> why not put these as plugins in the lzma and xz modules?
> 
> Auke

Why not: xz is replacement for gz for source packages.
xz/lzma has better compression than bz2 and gzip and decompression time much better than bz2.
It looks it will gain more acceptance than bz2.
Take a look at gnu.org ftp for example.
They skipped bz2 and provide for new releases xz and gz as backward compatibility.
Still downloading gz from their site is bandwidth waste.
Because the most key modules comes from gnu.org it is better for us to use xz.
Because in the future xz will have the same importance or greater than gz
it is better to have it in core plugin and on ISO.
As you may see in the patch xz is integrated into tar as 3rd unpacker (after gz and bz2).
That is why the easiest way was to extend generic-unpack plugin instead of adding plugin.
If you find generic unpack plugin to be decentralized I can write unpacker plugin
for bzip2 and gzip modules too to replace the generic one.
I found generic plugin supports all compressors supported by tar. Because tar supports
xz/lzma as 3rd compressor it is still obvious to me to add support for it to generic plugin.
lzma and xz are my prefered source packages. Next is bzip2 and gzip.
All future module updates from me will use lzma and xz if possible.

Let me know your decision.
I see sense of writing xz/lzma unpack plugin only when bzip2 and gzip also will be split to separate plugins.

have a nice day,
Zbigniew Luszpinski