Bugzilla Bug 210945

the .lzma snapshot tends to be ~90% of the .bz2 (so a savings of ~3meg):
27395597  portage-20080219.tar.lzma
30761597  portage-20080219.tar.bz2
239564800 portage-20080219.tar

and it takes about ~30% of the time (this is a ~2gigz amd64 system):
12.5s     time bzcat portage-20080219.tar.bz2 > /dev/null
4.0s      time lzcat portage-20080219.tar.lzma > /dev/null

lzma-utils is keyworded on all arches

won't this require long term support in portage before we can drop tbz2?  This
would imply that we would have to generate and ship both for some time(probably
a year)

portage peeps:  please advise.

It will be smoothest for users if we provide both types of snapshots for a
period of time (maybe a year or so). That way they can use an older version of
emerge-webrsync to fetch a bzip2 snapshot containing a newer version that
supports lzma snapshots.

"tbz2" is the short name for Gentoo binary packages.  however, we're talking
about snapshots, not binary packages here (for now!).

yes, we need emerge-webrsync first to be updated, that's why the bugs assigned
to portage.  i dont know anything about the snapshot process though to say what
all needs to be updated.

a transition period is ideal.

emerge-webrsync should support lzma files now if someone wants to give it a try

so what's the next step ?

I've adjusted the scripts on osprey/redtail to create the lzma snapshots. Now
there is a portage-20080316.tar.lzma snapshot that can be used to test
emerge-webrsync as soon as it propagates to the mirrors.

This is supposed to be fixed in portage-2.2_pre5 or earlier.

This is supposed to be fixed in portage-2.2_pre5 or earlier.

i just tested said version and it seems to be working for me

[   ] portage-20080319.tar.bz2                           20-Mar-2008 01:55  
30M
[   ] portage-20080319.tar.lzma                          20-Mar-2008 01:55  
26M

every meg counts ;)