On Sat, Nov 20, 2010 at 09:46:56AM +0900, Charles Plessy wrote: > Le Fri, Nov 19, 2010 at 11:06:51AM +0100, Holger Levsen a écrit : > > CDs wont grow in size and I'm pretty sure > > the desktop install sizes wont shrink. > > there is actually room for sparing a couple of megabytes, by chosing a more > efficient compression algorithm for the data tar archive in binary packages > like gimp for instance. Oh wow, going .gz -> .xz reduces the size in half -- and not only for gimp-data but also for a typical ELF file. And unlike bzip2, the cost is paid only during compression, decompression being hardly slowed down. Compression is significantly slower, but even on slowest architectures it is a tiny fraction of the time needed to build. On my cell phone compression of large files takes ~13 sec/MB, decompression 0.3 sec/MB (gzip 0.18 sec/MB). You can recompress arm packages on that 8 core amd64 machine nearby, too: ar x $PKG data.tar.gz && (gzip -cdf data.tar.gz|xz >data.tar.xz) && ar d $PKG data.tar.gz && ar r $PKG data.tar.xz Let's grossly overestimate and say that, if we include large data-only packages, the overall build time would increase by 1%. What would be the gains? HALVING[1] mirror usage, both disk and bandwidth, halving the time it takes to download a package, halving the number of CDs, enabling desktop users (ie, least technical) to install from a single CD, no noticeable slowdown of dpkg runs. Repacking the whole archive may be somewhat disruptive, but with this kind of massive gains, I'd say it's worth it even at this time in the release cycle. [1]. Measured on gimp + gimp-data, I'm repacking CD1-i386 as we speak to get a larger sample, on purpose on a slow machine to dismiss concerns about certain systems not being able to handle this. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice.
Attachment:
signature.asc
Description: Digital signature