[arch-general] [arch-dev-public] LZMA - in or out? ([signoff] libarchive 2.6.0 )

[Allan McRae]

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