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

Re: jigdo vs binary diff

On Thursday 10 June 2004 01:35, Richard Atterer wrote:
> On Wed, Jun 09, 2004 at 08:45:05PM +0300, George Danchev wrote:
> > what advantages I'll get when using jigdo to update my old image instead
> > of patching the old iso with rdiff.
> Well, Debian doesn't offer CD image upgrades in rdiff/xdelta format.
> Generally, IMHO jigdo has the following advantages over binary diffs:
> - jigdo allows you to update to your image from /any/ previous version of
>   the same image. That's most useful with weekly snapshots - imagine having
>   to download and apply 6 "patches" because you last fetched a weekly
>   snapshot 6 weeks ago.
> - you can download all the changed/new packages from any Debian mirror, not
>   just designated "CD patch mirrors". With patches, IMHO many regular
>   Debian mirrors would not be too excited about mirroring large patch
>   files, so the few mirrors who offered them would be fairly busy.
> - related to the point above: Debian does not need to duplicate the data
>   for the changed/new packages on the servers in a binary diff, which saves
>   space. (jigdo can download these packages from the "normal archive" of
>   packages on a Debian server.)
> - jigdo allows completely different kinds of "updates", e.g. you can update
>   from a set of CD images to one DVD image, without downloading all the
>   package data again.
> - jigdo updates still work fine in case your old CD has read errors.

Thanks for pointing these out. Your explanation is more that sufficient. I 
would add one more advantage of jigdo over rdiff:
- The new image might be piped instead of generated and stored on the server 
from debian-cd (or whatever) to jigdo-file to create the .jigdo/.template 
files. With rdiff one need to have the old and new image files to create the 

I think this comparing information is very important to clear the things up 
for the users and must be added to the jigdo's site and docs.

pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Reply to: