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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
