[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#805488: pristine-tar: Does not efficiently compress gzip --rsyncable, dpkg's default



Package: pristine-tar
Version: 1.33
Severity: important

(This bug may be a duplicate of other ones filed against pristine-tar; I haven't yet investigated their cause.)

pristine-tar seems not to know how to efficiently re-compress files compressed by gzip --rsyncable on both Jessie and Sid (which have gzip 1.6-4). From a Sid chroot:

$ gunzip pristine-tar_1.33.tar.gz
$ gzip --rsyncable pristine-tar_1.33.tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz; storing 80% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)

No such error happens if you leave off --rsyncable.

In fact, this happens on the unmodified tarball of pristine-tar itself (versions 1.31, 1.32, and 1.33, but not older versions):

$ apt-get source --download-only pristine-tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz; storing 86% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)

I noticed this because uscan's repack mode calls mk-origtargz, which uses Debhelper::Compression, which uses Dpkg::Compression, which passes --rsyncable by default. From /usr/lib/perl5/Dpkg/Compression.pm:

    gzip => {
        file_ext => 'gz',
        comp_prog => [ 'gzip', '--no-name', '--rsyncable' ],
        decomp_prog => [ 'gunzip' ],
        default_level => 9,
    },

So I bet this affects a number of packages. For instance, this is how pristine-tar's own native tarballs were made:

$ gunzip < pristine-tar_1.33.tar.gz | gzip -9 --no-name --rsyncable | diff -s - pristine-tar_1.33.tar.gz
Files - and pristine-tar_1.33.tar.gz are identical

The changelog entry for pristine-tar 1.14 (August 2011) implies that it's supposed to support the --rsyncable option already, but perhaps since then, the gzip format has changed.

--
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com


Reply to: