Hi Antonio, On Thu, Feb 28, 2013 at 11:20 PM, Antonio Diaz Diaz <[email protected]> wrote: > 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/
https://www.kernel.org/pub/linux/kernel/v3.x/ Please understand my position. It's not about preferring xz over lzip, or other way around. Maintaining three copies of LZMA (de)compressors with virtually identical performance would be a mistake. The current situation looks pretty simple: lzip and xz are roughly the same feature-wise, but xz (fairly or not) managed to get much more widely adopted in current Linux distributions. Therefore, in their real-world use, Busybox users will need to unpack *xz* files. Such as kernel tarballs from kernel.org, distribution .rpms with internally-xz'ed cpio archives, and many other things. Therefore I don't see sufficient reason to add .lzip decompression support to bbox. You still have a way in, though. You have prepared _compression_ support too. That is something xz embedded doesn't provide. Anyone who wants to _create_ a .xz file using bbox is potentially your client. Unfortunately, there won't be many people interested in creating .lzip files. If you can you change your code so that it produces valid .xz files (even if they are "stupid" in a sense that they are merely LZMA chunks w/o LZMA2 improvements), then I will take it. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
