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.
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 ;)
