Debian Planet

Welcome to Debian Planet


Apt-get into it.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers’ Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You’re not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International



  • EsDebian


  • DebianWorld


  • MaximumDebian


  • DebianUsers


  • Debian-BR


  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you’ve written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.


    DP is sponsored by Xinit Systems and

    Domains paid for and hosted by

    Buy your Debian merchandise at

    Who’s Online

    There are currently, 83 guest(s) and 5 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.


    existing solutions… (Score: 1)
    by abo on Thursday, November 01 @ 00:00:13 GMT

    There are two parts to this problem; changing Package files, and changing packages.

    The first, which people appear to be keen to optimize, is already solved by rsync. I use apt-proxy on my 28.8k link and it’s use of rsync as the backend saves me _heaps_ of package downloads.

    The second is trickier. There are several problems; the packages change names, and a small change to a package can make a big binary difference.

    The name change problem means rsync sees it as a different file, and hence doesn’t even attempt a delta-update. This can be fixed by using clever heuristic name matching to find a suitable old package to use as a basis.

    The big binary difference problem means any delta-update doesn’t save you anything. It would help a little if packages used rsyncable gzip, but this still doesn’t take into account a one line source change can totaly change a compiled binary. Ironicly, bsd’s use of cvsup to distribute source rather than binary packages could save you bandwidth for this reason.

    There is no point in solving the big binary difference problem untill you’ve solved the name change problem. The best solution of all would be for package mantainers to take more care when creating packages, so we don’t get new “fix stupid dendancy mistake” type packages every day, but this goes against the “release early” philosophy.

    There are other more esoteric solutions… xdelta mentions an extended http server/proxy that stores deltas for all versions of objects, allowing clients to request a particular delta between any two versions (using an md5sum as a key to identify versions). This gives you very optimized deltas at the cost of the server keeping every single version in delta format. Once you go down this path, you can do all sorts of wierd things like having client/server negotiate deltas for uncompressed versions of compressed objects. However, you introduce a whole new client/server/protocol to the net, and all the headaches that entails.

    Bottom line: all this is all very exciting, but please don’t re-invent a wheel… Instead use and contribute to what is already out there.


    Your Name: Anonymous [ New User ]



    Allowed HTML:
    <p> <b> <i> <a> <em> <br> <strong> <blockquote> <tt> <li> <ol> <ul>