On Thu, Feb 07, 2008 at 02:03:29PM +0100, Xavier wrote:
I was also wondering about the status of xdelta itself.
1) From http://code.google.com/p/xdelta/ :
Xdelta is a tool and library for differential compression. Xdelta release version 3 supports VCDIFF encoding and decoding. This is a BETA release, but almost stable. Supports compressing 64 bit files on Windows, Linux, etc.
Xdelta 1.1.4 is the last stable release. Xdelta 1.1.0 was released in 1999.
So, the arch package will be updated to xdelta 3 only when it is marked stable, right? Since it's almost stable, maybe this could happen in the near future. Will this cause any problems on pacman side?
Both versions of xdelta can be installed at the same time. xdelta1 consists of /usr/bin/xdelta, libedsio, libxdelta, and include files. xdelta3 is simply /usr/bin/xdelta3. Probably the easiest way to handle this would be to create a seperate package for xdelta3 so pacman can continue to use xdelta1 as long as needed. If we decide to go with the xdelta3 API, users will not actually have to install xdelta at all. See my comments below.
2) There was also a comparison of both there : http://bbs.archlinux.org/viewtopic.php?pid=255687#p255687 "The only advantages of xdelta3 I see right now is its reduced disk-space usage during delta creation, and the possibility of completely closing the rather unimportant md5 hole without extra patching time/disc-space. That and it seems to be generally a bit quicker in patching."
This benchmark was made 8 months ago though, so xdelta3 might be even better now.
3) Also when xdelta 3 is stable, we will have the alternative to use the API. It looks like we could simply do a copy / paste of the code() function there which is ~100 lines : http://code.google.com/p/xdelta/source/browse/trunk/xdelta3/examples/encode_...
Then it's just a matter of using fopen, calling that code function, and then fclose.
But while using the API looks cleaner, Dan had several arguments against doing it: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009627.html
Quoting Dan's email:
1. Using the API does introduce yet another dependency for pacman...our ldd output is starting to get a bit lengthy for what I feel should be a low level tool. If someone doesn't ever use the delta features of pacman, they would still have to have xdelta installed (because of the dynamic link at runtime, and yet some more mem usage).
One of the nice(?) things about xdelta3 is that everything is in one file: xdelta3.c. The encode_decode_test.c posted above does not link with any library; it just includes xdelta3.c. Users will not have to install anything extra to get delta support in pacman. The encode_decode_test is 58K when compiled with -O3.
2. xdelta3 tarball was chmodded all wrong. Please tell me the developer just made a mistake here, otherwise it is very windows focused. And the configure script is no longer there...
The latest tarball looks ok. There is still no configure script, but the Makefile works fine.