[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Binary Deb 'Diffs'

On Thu, 16 Sep 1999, Jordan Mendelson wrote:

> Just a quick idea, instead of having to download an entire package where 95%
> of the files don't change, what about downloading a type of binary diff? I can
> think of two ways to do it:

I've wanted something like this for a while -- I was also wondering
whether it would solve the PINE problem: the package could be
distributed as what appears to be a standard .deb file, but inside
there would be not only an original archive, but a binary patch
that dpkg-deb would automatically apply when unpacking -- neat?
If that solution did indeed get round UWashington's silly
licence, it would be a nice way of making it transparent to the
user, and sticking two fingers in UW's face at the same time.

> 1) Package everything in a type of 'pdeb' (patch deb). It should contain
> reconfiguration information, and files which have changed since version
> locally installed

Well, without getting so elaborate, most people have the old .deb
files sitting around, if not on CD-ROM on in their home directories,
in /var/cache/apt/archives.  It would be feasible just to distribute
a plain binary patch.

Notice that a plain binary diff between two .deb won't be much
use, due to `randomisation' by compression.  I think you'd need
to distribute an actual `diff -uRN' between the two unpacked
source trees, along with the new configuration files.

> 2) Package everything in a 'pdeb' w/ real binary diff. Instead of packaging
> entire files which have changed, package patches. This would require a system
> which logged changes in order to work correctly, similar to CVS.

Um, this is complicated (incremental package-by-CVS), and I
doubt it'll ever see the light of day, nice as it would be.
I think it would be simpler for master to just `dpkg -x' on
every upload, and diff against the existing file.

> Both of these would need to include a checksum per file. Optimally it would
> require that the storage of deb's on HTTP and FTP servers change as well,
> requiring the files to be unpacked so apt can grab a single file from a .deb.

Well, I think the best way of doing it would just be to store
all the patch files in the same current places as the .debs
are stored, with descriptive filenames that identify from which
to which versions they convert.  Of course, people won't want the
main tree being cluttered up with all this, so perhaps all the
patch files could be stored on a separate server.

> I don't know, I figured it might be a way to save bandwidth & disk space.

I don't think this is going to save anyone any disk space.
What I think it will save is bandwidth to the `end-user' -- those
using apt-get.  Remember that `rsync' has difference functions
in it already.

Chris <chris@fluff.org>                         ( http://www.fluff.org/chris )

Reply to: