Denys Vlasenko wrote:
Why?. *.lzma are deprecated some time ago
Because someone submitted the code:
I also submitted the code[1]. :-)
[1] http://lists.busybox.net/pipermail/busybox/2012-December/078750.html
In fact, it is surprisingly small:
archival/libarchive:
text data bss dec hex filename
2827 0 0 2827 b0b decompress_unlzma.o
7277 0 0 7277 1c6d decompress_unxz.o
2743 0 0 2743 ab7 decompress_bunzip2.o
5270 0 0 5270 1496 decompress_gunzip.o
Just the same size as lunzip minus the header and integrity checkings:
text+data text+rodata rwdata bss filename
2928 2928 0 0
archival/libarchive/decompress_lunzip.o
So basically, lzip lost the race wrt adoption. xz is used more widely.
Kernel tarballs are .xz, not .lz.
It depends on where you get your kernels from:
http://linux-libre.fsfla.org/pub/linux-libre/releases/3.8-gnu/
BTW, xz files are a bit smaller than lz files in the above directory,
but you need twice the memory to decompress them. Of course lzip can
achieve the same (or better) compresion if you add "-s 64MiB" to the
command line.
What I'm saying is that bbox project would like to have is (ideally)
_one_ LZMA decoder. Unpacking the compressed stream from two formats
isn't a terribly difficult thing.
But xz is not (only) a LZMA encoder, therefore no LZMA decoder will ever
be able to decode xz streams.
But can lzip decompress unxz *stream*?
If we have learned something from this thread is that not even all
unxz's can decompress all xz streams. Much less verify their integrity.
Regards,
Antonio.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
