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 <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )
