Debian and the case of Deb-delta

This longish post attempts to shed light on a new functionality while upgrading called deb-delta and how it can save some bandwidth and some issues therein.

Image via Wikipedia

Hi all,
What happens when you want to update and upgrade your system. In almost all GNU/Linux distributions (whether its rpm-based or deb-based) you do three things :-

a. Update your index :- The index is something like a high-level database where one just downloads some *y* file from a *z* place and compares it with an *x* file. X, Y and Z are all variables meaning they can be changed anytime. There are of course rules of how these files should look like and what format they should be under . The two files (X and Y) are both downloaded, then compared and from the comparisons the updater knows what and how many files have changed in the archive.

b. Download the new files

c. Install and new files (and any new configuration files) and remove the old files with their configuration.

Now, for a long time downloading the index itself would be in the range of MB’s within some time frame. Of course, it depends on the change (churn) of the packages in the index. Whereas the stable archive may have few updates in days/weeks etc., in unstable/sid changes are to the tune of changes every few hours while experimentally even more so.

Few months back with the help of the InRelease files and DiffIndex files. If you are interested you can always refer to man-files of diff-index download and diffindex-rred . Just to take an excerpt from the man page :-

diffindex-download is a command line tool for downloading Contents files. It uses APT’s diff/Index format patches when available to avoid downloading the full file. diffindex-download is used by apt-file.

Both the tools diffindex-download and diffindex-rred are used internally by your favorite update mechanism. From now on, for all purposes I would be using aptitude as my update and upgrade mechanism as I’m pretty much comfortable with it.

Below is an e.g. of a typical update done :-
~$ sudo aptitude update
[sudo] password for shirish:
Ign http://deb.opera.com stable InRelease
Hit http://deb.opera.com stable Release.gpg
Hit http://deb.opera.com stable Release
Hit http://deb.opera.com stable/non-free amd64 Packages
Ign http://deb.opera.com stable/non-free TranslationIndex
Get: 1 http://ftp.debian.org sid InRelease [146 kB]
Get: 2 http://ftp.us.debian.org sid InRelease [146 kB]
Ign http://deb.opera.com stable/non-free Translation-en_IN
Ign http://deb.opera.com stable/non-free Translation-en
Ign http://mozilla.debian.net experimental InRelease
Hit http://mozilla.debian.net experimental Release.gpg
Hit http://mozilla.debian.net experimental Release
Get: 3 http://ftp.debian.org testing InRelease [135 kB]
Get: 4 http://ftp.us.debian.org experimental InRelease [139 kB]
Ign http://ftp.debian.org stable InRelease
Get: 5 http://ftp.debian.org sid/main Sources/DiffIndex [2,038 B]
Hit http://ftp.debian.org sid/contrib Sources/DiffIndex
Hit http://ftp.debian.org sid/non-free Sources/DiffIndex
Hit http://ftp.debian.org stable Release.gpg
Hit http://ftp.debian.org testing/main Sources/DiffIndex
Hit http://ftp.debian.org testing/contrib Sources/DiffIndex
Hit http://ftp.debian.org testing/non-free Sources/DiffIndex
Get: 6 http://ftp.debian.org sid/main 2011-05-29-0812.31.pdiff [1,722 B]
Get: 7 http://ftp.debian.org sid/main 2011-05-29-0812.31.pdiff [1,722 B]
Hit http://ftp.debian.org stable Release
Hit http://ftp.debian.org stable/main Sources
Hit http://ftp.debian.org stable/contrib Sources
Hit http://ftp.debian.org stable/non-free Sources
Get: 8 http://ftp.us.debian.org testing InRelease [135 kB]
Err http://www.debian-multimedia.org sid InRelease
Err http://www.debian-multimedia.org sid Release.gpg
Could not resolve 'www.debian-multimedia.org'
Ign http://ftp.us.debian.org stable InRelease
Get: 9 http://ftp.us.debian.org sid/main amd64 Packages/DiffIndex [2,038 B]
Hit http://ftp.us.debian.org sid/contrib amd64 Packages/DiffIndex
Hit http://ftp.us.debian.org sid/non-free amd64 Packages/DiffIndex
Ign http://ftp.us.debian.org sid/contrib TranslationIndex
Get: 10 http://ftp.us.debian.org sid/main TranslationIndex [2,264 B]
Ign http://ftp.us.debian.org sid/non-free TranslationIndex
Hit http://ftp.us.debian.org experimental/main amd64 Packages/DiffIndex
Ign http://ftp.us.debian.org experimental/main TranslationIndex
Hit http://ftp.us.debian.org stable Release.gpg
Get: 11 http://ftp.us.debian.org sid/main amd64 2011-05-29-0812.31.pdiff [2,957 B]
Hit http://ftp.us.debian.org testing/main amd64 Packages/DiffIndex
Hit http://ftp.us.debian.org testing/contrib amd64 Packages/DiffIndex
Hit http://ftp.us.debian.org testing/non-free amd64 Packages/DiffIndex
Ign http://ftp.us.debian.org testing/contrib TranslationIndex
Get: 12 http://ftp.us.debian.org testing/main TranslationIndex [2,264 B]
Ign http://ftp.us.debian.org testing/non-free TranslationIndex
Get: 13 http://ftp.us.debian.org sid/main amd64 2011-05-29-0812.31.pdiff [2,957 B]
Hit http://ftp.us.debian.org stable Release
Hit http://ftp.us.debian.org stable/main amd64 Packages
Hit http://ftp.us.debian.org stable/non-free amd64 Packages
Hit http://ftp.us.debian.org stable/contrib amd64 Packages
Ign http://ftp.us.debian.org stable/contrib TranslationIndex
Hit http://ftp.us.debian.org stable/main TranslationIndex
Ign http://ftp.us.debian.org stable/non-free TranslationIndex
Ign http://ftp.us.debian.org sid/contrib Translation-en_IN
Ign http://ftp.us.debian.org sid/contrib Translation-en
Ign http://ftp.us.debian.org sid/non-free Translation-en_IN
Ign http://ftp.us.debian.org sid/non-free Translation-en
Ign http://ftp.us.debian.org experimental/main Translation-en_IN
Ign http://ftp.us.debian.org experimental/main Translation-en
Ign http://ftp.us.debian.org testing/contrib Translation-en_IN
Ign http://ftp.us.debian.org testing/contrib Translation-en
Ign http://ftp.us.debian.org testing/non-free Translation-en_IN
Ign http://ftp.us.debian.org testing/non-free Translation-en
Ign http://ftp.us.debian.org stable/contrib Translation-en_IN
Ign http://ftp.us.debian.org stable/contrib Translation-en
Ign http://ftp.us.debian.org stable/non-free Translation-en_IN
Ign http://ftp.us.debian.org stable/non-free Translation-en
Fetched 713 kB in 1min 23s (8,527 B/s)

See the whole index updated with a paltry 713 KB downloaded which used to have a typical 10 MB+ download.

The real magic is when one goes to /var/lib/apt/lists and checks one of the InRelease files. Here’s a very shortened version of the file :-


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Date: Sun, 29 May 2011 08:20:21 UTC
Valid-Until: Sun, 05 Jun 2011 08:20:21 UTC
Architectures: amd64 armel hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian x.y Unstable – Not Released
MD5Sum:
eb5585811b9cf7577db862095b050749 19645193 Contents-amd64.gz
6cf5ed2ed04e842bbf66d971970f7826 19355434 Contents-armel.gz
27fad3f87ddaa842b0b7a6636799caa0 17551863 Contents-hurd-i386.gz
8d06f657c86ffad25a2714cbd2aafbb8 19743250 Contents-i386.gz
7586051cf5006049b7969a43d1f4ed38 19229860 Contents-ia64.gz
ac42daa23e201a77516b1bdca24602cf 18751162 Contents-kfreebsd-amd64.gz
d23bc3c7cf31b70e97f5c1a5a8d4d313 18766674 Contents-kfreebsd-i386.gz
12ea04bf5518483756a7c43fa060e5fb 19283869 Contents-mips.gz
2787f1dd881a601f71912aa8e561a38b 19316287 Contents-mipsel.gz
b8d81535c64d1e6210f67c2da9aca1c6 19581703 Contents-powerpc.gz
57ef13d00d5b4a62378eee587e2241a4 19271675 Contents-s390.gz
1959d716cd89e443d02d6731c05f4f2c 19397776 Contents-sparc.gz
4a74cff9620ce07000a571b2de1b1066 2023 contrib/Contents-amd64.diff/Index
764fb7e4aeef0697741578a560a5a983 87312 contrib/Contents-amd64.gz
……..
……..
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJN4gHfAAoJEK7UsG9HMEH6Y4sQAKfAivISW5GQHhtHlHmRZ9rv
bqZVUZn0c0nkshrnyzHL+iqiZ7Ga75ddb7uqIvgc0hzeNByFSUVPm0WjY9ft+N9G
PBp6R2l0FsLp8M9EflGHTaBNUw+ZL7CwEpI4/OD2lXiW/Gzj/0zDE6Tlb/aav4Zs
vPqKu7Y/+qRHR/znUiGyN+F+ePxgk7ZYM7VoseNazf3pNZTv5Yqak/6Sb8pO71SQ
f2XWqVvdzaaHXF+KC1GI97h0xmmEt3dRqq0gaGUlctYEoAyXMyLzydL3ZljOtz35
m/l28jwOStyr9lvajapFM+/kDPAd2c5N7KriJ1D5RU/Aj8c5dKRiKys7q9nly5or
vFCPplcnOd3NYWE7JH7Oo3lmsHZ2mkkZpnev9G3fYD5YT8uiRK/26SUpJTM7xhDk
D7u0tluo0h9i0kWb9dx2GHut0+xc/XnTF9x67lqucxY2r5ymuP1Kwo6EBdRIEzqZ
PPA0noX8KdmSSlWs6pCeTrTvCZL4O5F7mSOVnE74zIPWTBvLXdo8LJtdHJIHfWNC
mLooIBvn/jBhGa/BRaoFLIzRLKuv2mA/kiNp/HlnqARJ0HWm27PM2Uy/CjrrJJp/
220JzOI3Vub2IRMozaUoAEv1O5qFwsgzlzVZ30d22yK2hgFEr7TBA1nliYnpWVLP
wBVgbyu3hK/5NZoAJnM/
=Ym0j
—–END PGP SIGNATURE—–

The SHA1 InRelease files work in part with the Index/diff files for security purposes, it’s the Index/diff files which are the real deal. A shortened typical diffindex file .

$ cat ftp.us.debian.org_debian_dists_sid_main_binary-amd64_Packages.IndexDiff

SHA1-Current: 23adaf0e7770919dbef39e6469ea2a762755983e 35521550
SHA1-History:
2cd6da66cf450f4ce0c0445b0b47b04008811b99 35357775 2011-05-26-0813.19
c3aff113722f906f77a84ae0481807c605d7fbed 35357868 2011-05-26-1412.05
........
........
SHA1-Patches:
b54ab9de64ec50738df740b987b9203a5a8f0856 3887 2011-05-26-0813.19
f54e264498f100857a9196ab0019f3a06acc05d4 34485 2011-05-26-1412.05
.......
........

The interesting point to note that while patches may increase and decrease over time, the package contents should always increase.

You also have the typical Packages file which would have a description of each package, something like this :-

$ cat ftp.us.debian.org_debian_dists_sid_main_binary-amd64_Packages

Package: 2ping
Version: 1.1-1
Installed-Size: 172
Maintainer: Ryan Finnie
Architecture: all
Depends: perl
Recommends: perl-modules, libio-socket-inet6-perl
Suggests: libdigest-sha-perl, libdigest-crc-perl
Description: Ping utility to determine directional packet loss
2ping is a bi-directional ping utility. It uses 3-way pings (akin to
TCP SYN, SYN/ACK, ACK) and after-the-fact state comparison between a
2ping listener and a 2ping client to determine which direction packet
loss occurs.
Homepage: http://www.finnie.org/software/2ping/
Section: net
Priority: optional
Filename: pool/main/2/2ping/2ping_1.1-1_all.deb
Size: 28310
MD5sum: 55b1dd708c968cf274374f0068c1b497
SHA1: e32ebc0409facb6dcc67ff04c513da2398400d16
SHA256: ab24035ddd7c5c12ef01cf5d88bdcc972731c22b208d9b9021ba2cdb5682d813
.........
.........

What should be noted of interest is the SHA1sum and SHA256sum of each package and the total number of packages. This would be unique perhaps to each machine as they would not have the same number of packages (in total) .

It’s just amazing what these guys have done. Signed releases, ‘valid until’ field, diffindexes, the works, very cool. Just by doing the above, they managed to decrease the bandwidth requirements at least in the Desktop scenario by 60~80%. In the Server environment it should also be helpful but not so much as the guys who run the servers typically do their own QA before letting any updates in. Also they usually do a lot of customization before putting anything up. So it would not be used as frequently as in a typical Desktop scenario.

For the Desktop though, this is/was just the beginning of the revolution. The real deal is a functionality called debdelta which should be part of the update mechanism either in wheezy (the next release) or wheezy+1 .

Deb-delta in many ways does the same job that Diff/Index does while updating index. To put it very loosely, it looks at the new debian package in the archive, compares it with the old and figures out the difference. If the difference between the two packages is less than 70% then it would make a deb-delta (which is kinda a patch file) which in-turn would patch the old deb with the patch so it becomes the new .deb. To put it simply :-

The old way :-
a. Old deb
b. Update index
c. Download the full new .deb file
d. Install the new deb.file and any configuration files
e. Remove the old deb file and any obsolete files

After deb-delta things are a bit different :-

a. Old deb
b. Update index
c. Compare the new .deb with the old deb and if difference is not =>70% then make a .debdelta file (this comparison is done at debdelta.net and the debdelta file is prepared at debdelta.net)
d. Download the .debdelta file
e. Patch the .debdelta file to the old deb
f. Install the old+patch file = new file
g. The rest is the same of installing the new file along with any conffiles and removing the old ones.

while the detailed explanation of how the whole thing works can be looked in the debdeltas, debdelta, debdelta-upgrade and debdelta-patch man pages as well as the debdelta-doc package. Look for the debdelta_suite pdf file. Below is a typical update and upgrade scenario played out using deb-delta upgrade.

$ sudo aptitude update
[sudo] password for shirish:
Ign http://deb.opera.com stable InRelease
Hit http://deb.opera.com stable Release.gpg
Hit http://deb.opera.com stable Release
Hit http://deb.opera.com stable/non-free amd64 Packages
Ign http://deb.opera.com stable/non-free TranslationIndex
Ign http://deb.opera.com stable/non-free Translation-en_IN
Ign http://deb.opera.com stable/non-free Translation-en
Get: 1 http://ftp.debian.org sid InRelease [146 kB]
Ign http://mozilla.debian.net experimental InRelease
Get: 2 http://ftp.us.debian.org sid InRelease [146 kB]
Hit http://mozilla.debian.net experimental Release.gpg
Hit http://mozilla.debian.net experimental Release
Get: 3 http://ftp.debian.org testing InRelease [135 kB]
Ign http://ftp.debian.org stable InRelease
Get: 4 http://ftp.debian.org sid/main Sources/DiffIndex [2,038 B]
.....
.......
........
Fetched 803 kB in 51s (15.6 kB/s)

Current status: 11 updates [+10], 51 new [+29].

The interesting things to point are in the two last sentences. The first one tells how slow the updating was (mirror issues, parallel-downloading of some other content, whatever it might be, it tells at what average downloading rate the diffs happened. I dunno though if it takes into account the amount of time done both when starting to update and at the very end when computing the results but that’s a side topic.

The real thing is when it says there are 11 updates and some new files. Please do not be alarmed as I try to see all new files and then do a forget-new hence you see a low number on new files.

Then just to know what the new updates are I ask for upgrade :-


$ sudo aptitude safe-upgrade
Resolving dependencies...
The following packages will be REMOVED:
libboost-program-options1.42.0{u}
The following packages will be upgraded:
cupt debdelta libcupt2-0 libcupt2-0-downloadmethod-curl libgnome2-0
libgnome2-common libmeanwhile1 openjdk-6-jdk openjdk-6-jre rss-glx
The following packages are RECOMMENDED but will NOT be installed:
icedtea-netx
10 packages upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
Need to get 19.8 MB of archives. After unpacking 220 kB will be freed.
Do you want to continue? [Y/n/?] n
Abort.


Now you can see the problem very clearly. Isn’t it mad that you or I have to download 20 MB of archives when after doing the whole thing it would be freeing some more space. Anyways let’s get a bit ahead :-

$ sudo debdelta-upgrade cupt debdelta libcupt2-0 libcupt2-0-downloadmethod-curl libgnome2-0 libgnome2-common libmeanwhile1 openjdk-6-jdk openjdk-6-jre rss-glx icedtea-netx
Delta is not present: debdelta_0.42exp_0.43_amd64.debdelta
Delta is too big: libcupt2-0-downloadmethod-curl_2.0.2_2.1.0_amd64.debdelta
Delta is too big: libmeanwhile1_1.0.2-3_1.0.2-4_amd64.debdelta
Downloaded, time 0.16sec, speed 27kB/sec, openjdk-6-jre_6b18-1.8.7-3_6b18-1.8.7-4_amd64.debdelta
Downloaded, time 0.17sec, speed 36kB/sec, rss-glx_0.9.1-5_0.9.1-5+b1_amd64.debdelta
Downloaded, time 0.37sec, speed 83kB/sec, libgnome2-0_2.30.0-1_2.32.1-1_amd64.debdelta
Created, time 0.90sec, speed 251kB/sec, openjdk-6-jre_6b18-1.8.7-4_amd64.deb
Downloaded, time 0.49sec, speed 125kB/sec, libgnome2-common_2.30.0-1_2.32.1-1_all.debdelta
Created, time 1.58sec, speed 3193kB/sec, rss-glx_0.9.1-5+b1_amd64.deb
Created, time 0.48sec, speed 986kB/sec, libgnome2-0_2.32.1-1_amd64.deb
Error: applying of delta for libgnome2-common failed: : Error, 88 locale files are absent. (non retriable)
Downloaded, time 18.58sec, speed 9kB/sec, cupt_2.0.2_2.1.0_amd64.debdelta
Created, time 0.54sec, speed 698kB/sec, cupt_2.1.0_amd64.deb
Downloaded, time 6.82sec, speed 31kB/sec, openjdk-6-jdk_6b18-1.8.7-3_6b18-1.8.7-4_amd64.debdelta
Created, time 4.28sec, speed 2497kB/sec, openjdk-6-jdk_6b18-1.8.7-4_amd64.deb
Downloaded, time 15.02sec, speed 28kB/sec, libcupt2-0_2.0.2_2.1.0_amd64.debdelta
Created, time 0.97sec, speed 727kB/sec, libcupt2-0_2.1.0_amd64.deb
Downloaded, time 66.65sec, speed 23kB/sec, libgnome2-common_2.32.1-1_all.deb
Delta-upgrade statistics:
total resulting debs, size 18MB time 141sec virtual speed 134kB/sec

22:56:29shirish@deb-home:~$ sudo aptitude install cupt debdelta libcupt2-0 libcupt2-0-downloadmethod-curl libgnome2-0 libgnome2-common libmeanwhile1 openjdk-6-jdk openjdk-6-jre rss-glx icedtea-netx
The following NEW packages will be installed:
icedtea-netx
The following packages will be REMOVED:
libboost-program-options1.42.0{u}
The following packages will be upgraded:
cupt debdelta libcupt2-0 libcupt2-0-downloadmethod-curl libgnome2-0
libgnome2-common libmeanwhile1 openjdk-6-jdk openjdk-6-jre rss-glx
10 packages upgraded, 1 newly installed, 1 to remove and 1 not upgraded.
Need to get 695 kB/20.3 MB of archives. After unpacking 431 kB will be used.
Do you want to continue? [Y/n/?] Y
Get: 1 http://ftp.us.debian.org/debian/ sid/main debdelta amd64 0.43 [102 kB]
Get: 2 http://ftp.us.debian.org/debian/ sid/main libcupt2-0-downloadmethod-curl amd64 2.1.0 [39.8 kB]
Get: 3 http://ftp.us.debian.org/debian/ sid/main libmeanwhile1 amd64 1.0.2-4 [93.8 kB]
Get: 4 http://ftp.us.debian.org/debian/ sid/main icedtea-netx amd64 1.1~20110510-1 [460 kB]
Fetched 695 kB in 25s (27.5 kB/s)
Reading package fields… Done
Reading package status… Done

The more interesting parts are in the deb-delta upgrade as they give some idea of the nature of things and the sort of things you can expect when handling the tool. Let us scan the resulting output and see some of the more interesting things that occurred in the output :-

$ sudo debdelta-upgrade cupt debdelta libcupt2-0 libcupt2-0-downloadmethod-curl libgnome2-0 libgnome2-common libmeanwhile1 openjdk-6-jdk openjdk-6-jre rss-glx icedtea-netx

Delta is not present: debdelta_0.42exp_0.43_amd64.debdelta

This is the first kind of output where there is no debdelta made of the file. There are and could be
any number of reasons for the above failure, right from connection not being made to the debdelta.net domain for the service to some error while making the debdelta_0.42exp_0.43_amd64.debdelta . If you want, you can always try later and sometimes it would pan out, sometimes it doesn’t. And that is one of the issues. No consistency as well as cryptic explanation.

Delta is too big: libcupt2-0-downloadmethod-curl_2.0.2_2.1.0_amd64.debdelta
Delta is too big: libmeanwhile1_1.0.2-3_1.0.2-4_amd64.debdelta

This one is easy to figure out. When you get statements saying Delta is too big, it means the difference between the two packages is more than 70% in which case it makes sense to download the new package in full rather than use the delta as there would be no bandwidth saving and instead a bit more bandwidth used when downloading a .delta.


Downloaded, time 0.16sec, speed 27kB/sec, openjdk-6-jre_6b18-1.8.7-3_6b18-1.8.7-4_amd64.debdelta
Downloaded, time 0.17sec, speed 36kB/sec, rss-glx_0.9.1-5_0.9.1-5+b1_amd64.debdelta
Downloaded, time 0.37sec, speed 83kB/sec, libgnome2-0_2.30.0-1_2.32.1-1_amd64.debdelta
Created, time 0.90sec, speed 251kB/sec, openjdk-6-jre_6b18-1.8.7-4_amd64.deb


The interesting thing to look here is the first downloaded line and the last Created line. Let’s look at the two lines which make sense when they are together.


Downloaded, time 0.16sec, speed 27kB/sec, openjdk-6-jre_6b18-1.8.7-3_6b18-1.8.7-4_amd64.debdelta
Created, time 0.90sec, speed 251kB/sec, openjdk-6-jre_6b18-1.8.7-4_amd64.deb


Ah, now it makes sense. In the first line I just download the patch/debdelta file. In the second created line it has patched that debdelta file to the old.deb file itself.

Here’s another one with a different output :-

Downloaded, time 0.49sec, speed 125kB/sec, libgnome2-common_2.30.0-1_2.32.1-1_all.debdelta
Created, time 0.48sec, speed 986kB/sec, libgnome2-0_2.32.1-1_amd64.deb
Error: applying of delta for libgnome2-common failed: : Error, 88 locale files are absent. (non retriable)


Now this is a bit more complex. It downloaded the .debdelta file, tried to patch the files but failed as the locale files are/were absent. It’s partly my fault and partly the developer’s fault.

I have been also using the services of a package called localepurge. To share what localepurge does, simply look at this excerpt from its man page :-

localepurge is a small script to recover disk space wasted for unneeded locale files and localized man pages. It will be automagically invoked by dpkg upon completion of any apt installation run.

Now from what little I know of the debian project, there are at least 14~15 odd languages which have been universally translated throughout the Debian ecosystem. Now as time goes on and interest in the debian-project is high, the number of locales are going to be more rather than less. One can look at the /usr/share/locale directory to find out how many locales are installed in your system .

In the short-term it is/would be wise for the developer to just not download the .debdeltas of packages which have their locale information removed. I am sure this is doable but would it add more time/latency for doing that or not, not sure. Also the developer would maybe have to re-write quite a bit of code to do some things before rather than later. The re-write could be for better or not, have no idea. Only the developer in question can answer that.

The more long-term solution is to somehow figure out which locales are in the system and which are not and try to download only those locale files. Now I don’t know any programming so dunno if this can be done. Even if it can be done, should it be done and what the costs would be (as in time, latency and complexity) . The way I see it, its difficult as one could have any number of locales the user feels like. On top of it, one cannot say if the locales are consistent with any given package at any point in time. For e.g. when major changes in UI occur, a new major version, there are usually lesser number of translators and hence lesser locales. As it becomes part of the ecosystem there may be more people to help in the translation. So the developer would need to figure out how many locales are there in any system (easy), figure out if apart from the delta of the package, the locales are cherry-pick downloadable (hard). While this could also be probably accomplished, without some tests it would not be easy to know if the hard work done is worth it or not. What is true though that the number of locales would always increase (I hope).

The interesting thing is really at the end of the debdelta upgrade cycle. Look at the stats at the very end :-

Delta-upgrade statistics:
total resulting debs, size 18MB time 141sec virtual speed 134kB/sec


Now that is the real winner. My connection is a pretty lame 256 Kbps 300 ms latency filled connection, nothing really to write home about. 256 kbps per second translates loosely to 30 Kb/sec and debdelta-upgrade refers to 134 Kb/sec around 5 times my connection speed. If bigger files are there one can expect even more dramatic speeds.

The last bit of using aptitude install just downloads those files which either had no deltas, are new packages or there were some problems with the deltas therein. There could be at times also problems with having faulty debs where the developers encourage to write bug-reports telling of the troubles. Make bug-reports using tools like reportbug or reportbug-ng like this :-

$ reportbug debdelta

The developers also welcome patches and stuff so if you are a student, have time and want to do something interesting and useful this is something to play with.

That’s all for now.