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
