Thomas Bächler wrote:
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.
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...
Allan
