Revision 1 as of 2011-05-23 09:31:56

Clear message

Debdelta support in libapt


Debdelta provides a way to avoid downloading the entire debfile by providing "delta" files that can then be used to reconstruct the deb. This is beneficial for users with slow network connections or metered connections.


The design broadly follows what was needed to implement the pdiff feature that allows downloading/applying deltas for the Packages.gz file.

The highlevel picture of supporting debdelta inside libapt is:

  1. add a new debdelta method in methods/ just like e.g. methods/
  2. add support for downloading the "debdelta" file in apt-pkg/acquire-item.{cc,h} in pkgAcqArchive
  3. after a debdelta file was successfully downloaded from pkgAcqArchive queue it for processing with the debdelta apt method.

Step (1) can initially just call debpatch and moves the resulting deb from /var/cache/apt/archives/partial to /var/cache/apt/archives. However we need to investigate how progress of the patching can be reported and displayed to the user via the standard apt support for this. Patching can take a long time for big packages, so having progress support for this is essential for a good user experience (even though it does not have to be 100% accurate).

For step (2) when there is no indexfile for the deltas it will have to do a http GET and then on a 404 fallback to the regular deb. Without a indexfile calculating the required download is also not possible. For this we need some sort of index, maybe in Packages.gz or as a seperate file. This needs to be discussed with the debdelta upstream (and the index should be optional as it adds a additional download cost). We also need to ensure that we check the signature of the downloaded debdelta file. It contains a shell script that does the patching, so we must be certain that there haven't been man-in-the-middle or server side attacks.

For step (3) we should also verify the signature of the resulting deb. debdelta is already doing this on the server side when building the delta but having the client also checking is also useful. Currently we have to trust the debdelta server a great deal as there is a shell script executed as root for reconstructing the deb, but eventually we may run the script in a very contained environment using e.g. lxc containers as non-root. In order to efficiently verify the deb we need to investigate if we can store a uncompressed sha256 of the deb in the indexfile to avoid the need to recompress the deb just for the verification check.