[arch-general] [arch-dev-public] LZMA - in or out? ([signoff] libarchive 2.6.0 )
allan at archlinux.org
Tue May 12 06:31:19 EDT 2009
Thomas Bächler wrote:
> Pierre Schmitz schrieb:
>> I am just doing some very simple test right now. (default compression
>> core (x86_64) (decompress time)
>> none 552M
>> gzip 186M 12s
>> xz 121M 17s
>> I will add a test for extra later.
>> Even though this might not be a really valid benchmark it show that
>> its defintely worth it. Most people will benefit from a smaller
>> download size which should also comensate the slightly increase
>> decompression time. (I don't think that a lot of people download 65MB
>> within 5s)
> Agreed. This is not even a hard transition: It should be no problem to
> have mixed gzip and lzma packages in the repos, so this will be a
> smooth transition (only new packages will be rebuilt, old ones will
> stay as they are). pacman doesn't care how it is compressed, as long
> as libarchive supports it, so the user shouldn't even notice (we
> should only ensure that pacman and libarchive stay gzip for a while).
> Does repo-add/dbscripts/devtools do anything gzip-specific? If so,
> it's probably easy to get rid of.
Pacman needs no changes as far as I am aware. makepkg only can
generation gzip and bzip2 packages, so someone has to patch that. The
ftp clean-up script uses PKGEXT from makepkg.conf so would probably need
an ugly fix to look at multiple extensions. db-update and db-move both
use PKGEXT, so there will need to be dual db-scripts if
pacman/libarchive/libfetch etc need to be in a different compression.
Overall, I'd prefer to spend my time getting pkg deltas working which I
think is the better bandwagon to jump on...
More information about the arch-general