[pacman-dev] delta support in libalpm
Henning Garus
henning.garus at googlemail.com
Thu Nov 13 19:03:53 EST 2008
On Thu, Nov 13, 2008 at 9:31 PM, Henning Garus
<henning.garus at googlemail.com> wrote:
> On Mon, Nov 10, 2008 at 8:38 AM, Allan McRae <allan at archlinux.org> wrote:
>> Henning Garus wrote:
>>> Yes you do. libalpm uses system() to execute:
>>> xdelta patch [deltafile] [oldpkg] [newpkg]
>>>
>>> xdelta will unzip the old package, apply the patch and rezip the new
>>> package.
>>> Due to the zlib/gzip inconsistencies the md5sum for the patched
>>> package can differ from the md5sum of the new package, which was
>>> zipped with gzip. Unless that line is changed to something like
>>> xdelta patch -0 [deltafile] [oldpkg] - | gzip -cn > [newpkg]
>>
>> Is any of this fixed by using the xdelta3 branch? From memory that does not
>> use gzip/bzip2.
>
> According to http://xdelta.org/xdelta3.html xdelta3 uses a builtin
> compression to compress the delta files (xdelta1 uses zlib). However,
> you won't get around decompression and recompression when using deltas
> with compressed files. When xdelta3 gets compressed files as input it
> will use the appropriate external compression engine to decompress the
> inputs and compute a delta. It do that again to compress the output
> after patching. So basically it will do the same, as my original
> proposal 2, only internally. It could be interesting nonetheless,
> because with xdelta3 deltas would probably work for bzip2 compressed
> packages, without any further changes in pacman.
>
> Henning
>
I guess I spoke to soon. I was right concerning xdelta3 using gzip for
handling gzipped files, however it doesn't use the -n flag. This gives
us the same behaviour as xdelta1, with one minor difference: Method 1.
stops working.
More information about the pacman-dev
mailing list