to LZMA or not to LZMA

Harald Sitter apachelogger at ubuntu.com
Tue May 26 22:12:18 BST 2009


Proposal for long-term LZMA usage:
http://en.wikipedia.org/wiki/LZMA

Add it to our CDBS magic.

In Jaunty Jonathan Thomas introduced LZMA compression to some packages, 
especially decreasing the size of dbg packages a lot. In Karmic those changes 
were lost due to merging, which made me remember the original idea I had.

The compression method should be handled within our CDBS makefile and not 
within the individual rules files.
There are two reasons for that:
1. It can be managed in a central place (which also helps keeping an overview 
of what is LZMAified and what is not)
2. Disabling it on a global scale becomes a lot easier

So, my current concept is to have it enabled by default for every build using 
debian-qt-kde.mk. LZMA in general allows for much better compression than gzip 
or even bzip2. The downside however is that it requires a lot more resources 
at compression time, but at decompression is somewhere in between bzip2.
Simply put: lzma is between gzip and bzip2 rating by decompression time but 
mostly providing the best compression of all 3.

A blog post about LZMA:
"Lzma is definitely worth a look due to its performance - if you unpack much 
more often than you pack (three times slower than already-not-so-quick 
bzip2!). Also, lzma works better on large files. From a distribution 
standpoint, if/when the library/dependency problems have been sorted out, lzma 
is quite preferable, if you don't do much compression yourself, yet have to 
watch your bandwidth usage."
http://blog.i-no.de//archives/2008/05/08/index.html#e2008-05-08T16_35_13.txt

Slax, for example, uses LZMA for every package AFAIK (Slax, being a Live 
System, is also facing the "how much stuff can I squeeze on one CD" problem)

The increased requirements at compression make the build time sometimes a lot 
longer, which is why you can deactivate LZMA compression (thus fall back to 
gzip, which is default) by exporting DEB_NO_LZMA=1.

If someone finds out how to check if we are on a buildd we could also reverse 
that and only use LZMA if the build is done on a buildd. That just made me 
realise, maybe we should add another option: no compression at all ... that 
might speed up testbuilds a bit ;-)

Anyway, please state any concerns regarding this proposal



More information about the kubuntu-devel mailing list