[pacman-dev] String freeze for 3.2 release

[Xavier]

On Wed, Jul 16, 2008 at 2:06 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
>> > How broken are they?  More specifically, does this code need some
>> > minor fixes or a complete overhaul?
>> >
>> > BTW, this is on my big changes to get into Arch list, right behind
>> > getting a testing repo for community.  I even maintain xdelta as a
>> > reminder.
>>
>> The libalpm code isn't broken at all, actually- it is just missing the
>> scripting side of things in makepkg or repo-add. These scripts need
>> the components to generate "delta 2.0" format, and we came across some
>> problems with that, including compression, timestamps, and checksum
>> mismatches.
>>
>> Xavier, do you remember where this all was? I thought this stuff was
>> on the ML but I'm not sure.
>>
>> -Dan
>>
>
> Oh, good to hear. Then I'm sorry about misleading info.  (I don't follow
> this delta stuff at all, that's why I referred to Xavier).
>

The gzip / md5sum issue was discussed here between Nathan and I :
http://www.nabble.com/Add-delta-creation-to-repo-add.-td15513733.html#a15838665

To quote Nathan :
> For the first patch, I added the -n flag to gzip in order to prevent the
> md5sum problem. The apply-delta script is not as efficient as it could
> be. There is an extra gunzip+gzip step that could be avoided if we
> create a delta on the .tar rather than the .tar.gz. Doing so would
> complicate makepkg a bit, so I stuck with the extra step.

This extra gunzip+gzip step is quite disappointing indeed, since the
purpose of delta is efficiency.
Working directly on tar would solve this problem but would cause
another : increased disk usage, because the old and new packages would
need to be both uncompressed at some point (and this affects both
delta creation and application).
Maybe we need new delta benchmarks taking this into account now,
before spending more time?

The second biggest problem is lack of motivation and interest from everyone.
What is the point of having delta support if no one is going to use them?
But if people are going to use them, then we need feedback about how
it should work.
I don't know whether it would be better to have delta being generated
at makepkg step, or repo-add step, or both.
We have to take into account both the simplicity of usage but also of
implementation, and try to avoid duplication if we need delta support
in both.
In the end of the above thread, I proposed a quick summary of an
implementation only at repo-add level, but I don't know if it is a
good idea or if it is too limited or what.