[OE-core] sstate compression

[Phil Blundell]

On Wed, 2012-01-04 at 09:32 -0700, Chris Larson wrote:
> Agreed. Sstate can get truly massive, being able to opt-into xz or
> something would be lovely for us as well.

Yes, that would be nice.  xz does seem to compress nearly twice as well
as "gzip -9", though it takes about six times as long to do it.  (16M
and 55 seconds vs 28M and 9.5 seconds for my webkit testcase.)
Personally I don't care about the disk space as much as the build time,
but I can see that sstate could start to become quite unwieldy if you
have a lot of packages in there.

Alternatively, maybe we could have sstate.bbclass accept multiple
compression types when reading (i.e. look for .tar.xz, .tar.gz, .tar.lzo
etc in turn), make it use the fastest reasonable compression when
generating the archives in the first place, and then folks who want to
either put them into long-term storage or send them over slow links can
post-process the sstate-cache by transcoding them into .xz or whatever
format.

p.