Pierre Schmitz schrieb:
I am just doing some very simple test right now. (default compression preset) 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.
Anyone else in favor of moving to lzma? Related: lzma-compressed kernel (support with 2.6.30 and newer), maybe lzma-compressed squashfs on the live CDs (2.6.30 has lzma support, no idea if squashfs can use it already).
Attachment:
signature.asc
Description: OpenPGP digital signature
