XZ embedded bug unpacking linux-3.8.tar.xz

[Antonio Diaz Diaz]

Dear Denys.

Denys Vlasenko wrote:
> Maintaining three copies of LZMA (de)compressors with
> virtually identical performance would be a mistake.

This can be easily solved by removing the deprecated one, as others are 
doing. The mistake here would be to reject lzip just to keep the 
deprecated lzma-alone.


> The current situation looks pretty simple:
> lzip and xz are roughly the same feature-wise,

The only feature for which lzip and xz are roughly the same is 
compression speed/size. Sadly it seems the only feature ever 
tested/cared for by most users.


> 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.

This sees users as consumers. What about the users who want to create 
their own compressed files?

Not counting that any Busybox user wanting to check the integrity of 
files will avoid xz files anyway. Kernel tarballs are also distributed 
in bzip2 format.


> Therefore I don't see sufficient reason to add .lzip
> decompression support to bbox.

All right. If you ever change your mind, just ask me for an updated 
patch. :-)


> 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.

I think there is a misunderstanding here. I am not seeking "clients". I 
am trying to be the change I wish to see in the world. I prefer to see 
my work rejected better than causing harm to humankind by working on a 
project I consider a mistake.

The lzip applet already produces full lzip files, not dumbed-down files 
like the ones an hypothetical xz applet could produce.


Regards,
Antonio.