5. Todo

5.1. todo list

  1. Prepare an APT method so that 'apt-get upgrade' would actually use deltas. Some code is already written. See also 2011 Google Summer of Code.

  2. As in Section 4.3.4. It would be nice if debdelta-upgrade would actually choose if

    • download a delta and use it to create the .deb

    • download the deb

    depending on which one would be faster. Unfortunately, this decision must depend on a good model to predict the speed of patching... and this I still cannot achieve.

  3. in debdelta-upgrade, have as many "patching thread" as there are cores

  4. upgrade debdelta-upgrade to newer libapt

  5. support multiarch

  6. collect data, benchmark! (some debdelta behaviours are coded in magic numbers that I got from thumb reasoning on small datasets)

  7. support long time exact recovery Section 4.5: embed a copy of gzip, libzip, bzip2 and lzma in debdelta??

5.2. things are getting worse

W.r.t. to when I started deploying debdelta, things got worse, for two reasons,

  1. one problem is Section 4.4

  2. delta backends are bad at compressing a binary that was compiled from the same source but with twi different compilers; see in particular the Google Courgette project, and compare it with the problems I encountered lately when Debian switched from GCC 4.4 to 4.5, when it happened that the binaries were so different that the compression of the new binary with LZMA would be smaller than the BSDIFF of the old and the new binary (!!). Unfortunately it seems that Google Courgette was hit with a patent infringment

so we should study how to reduce the size of deltas, and/or making them faster (possibly implementing lzma in xdelta3; or automatically choosing 'bsdiff' vs 'xdelta3' depending on the situation).