Deb binary diffs?

Paul Sladen ubuntu at
Sat Jan 24 15:11:02 GMT 2009

On Fri, 16 Jan 2009, Justin Dugger wrote:
> .

IIRC, it's actually futher along from than that; the code exists, but is
hackish; alot of the hackish is involved in the expectation that we repack
the .deb (when dpkg will then immediately unpack it again)

Some further research/optimisation needed doing on a machine with a localish
full mirror (but people. was/is Canonical only(tm)[1]).  mvo had a test
setup in his home folder, but I'm not/was not in a position to tinker.

To make things easier for an apt-sync, here's what needs doing:

  1. dpkg to allow 'data.tar'[0]
  2. hash of non-packed .deb in 'Packages.
     (Or rather, sign the data, not the result of the encoding)

Then it needs integrating with the build process (checksum building), for
Debian we have source; for Ubuntu that would have to be a Canonical employee.

Once done, for further optimisation (over download size):
  1. Debian/Ubuntu spec to allow any deflate packer (not just'gzip -9')
  2. Guide compressor using previous-version deflate tables/decisions
  3. Guide linker using previous-version linking decisions
  4. Guide Compiler using previous-version compiler decisions

Being on a boat and stuck behind GPRS, I'm actually a person that would gain
from this massively at the moment.

There's people pulling in different directions:

  (a) CD-size  (see Jani's message this week)
  (b) Mirror footprint
  (c) Download size
  (d) Upgrade size
  (e) Buildd load
  (g) Mirror CPU
  (f) Local load

Pick one, maybe two.  Canvas people.  You can't have (b) or (g).


[0] dpkg already allows non-packed 'control.tar', but not 'data.tar'
[1] I did ask at the time.
Why do one side of a triangle when you can do all three.  Somewhere, GB.

More information about the ubuntu-devel mailing list