enable XZ to compress updates?

That could only be done in two steps.
First, add xz in installed files, then compress next update with xz

I just tested 1.9.18 and 1.9.19 xz compressed with change in lfs/update like
this
 -cd /tmp && tar -c --xz --exclude=/tmp/patch.tar.xz -f /tmp/patch.tar.xz *
 # now remove everything except the package as other files are inside
 find /tmp/* -not -name patch.tar.xz -delete

This result in
ls -s1 ipcop-1.9.1?-update.i486.tgz
 8564 ipcop-1.9.18-update.i486.tgz
11320 ipcop-1.9.19-update.i486.tgz

vs using tar -cz
ls -s1 ipcop-1.9.1?-update.i486.tgz
12560 ipcop-1.9.18-update.i486.tgz
11988 ipcop-1.9.19-update.i486.tgz

The different behavior with 1.9.18 and 1.9.19 is interesting and show that
when data is already compressed like our kernel modules, that compress not
well with xz.

Uncompressing kernel modules before tar.xz creation allow a better
compression.
I add before tar.xz creation
 -find /tmp/lib/modules -name *.ko.gz -exec gzip -d {} \;

and this result to
ls -s1 ipcop-1.9.19-update.i486.tgz
8548 ipcop-1.9.19-update.i486.tgz

Of course, we would need the reverse after installation to not require more
space on disk, and that will cost another bit of time.
find /lib/modules/ -name '*.ko' -a -type f -exec gzip -nf9 {} \;

Time to compress one update is bigger, but less than initramfs creation
time.

Gilles


------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb