On Wed, Jul 16, 2008 at 2:06 PM, Nagy Gabor <ngaba@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#a15838... 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.