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

Re: Rsync and incremental updates on top of Original CDs



Hi Anne,

first of all, I should probably have mentioned the name that I have
/finally/ decided on: Jigsaw Download, or short jido. (I just hope
that "jido" doesn't happen to mean anything naughty in any language -
you never know... :)

On Tue, Feb 20, 2001 at 12:58:42PM +0100, J.A. Bezemer wrote:
> On Sun, 18 Feb 2001, Richard Atterer wrote:
> 
> > Note that I'm currently working on a tool which will allow you to say:
> > "Here's a CD full of files and an 'image template' (created for a new
> > CD, also by my tool) - please fetch any new deb's and re-use the other
> > files from the old CD."
> 
> Cool!
>
> You mention "the" old CD as if it were only one (which is very nice
> already), but since packages tend to get shuffled around a bit each
> time, it would be most useful to allow multiple local "repositories"
> (mounted or copied CDs, and /var/cache/apt/archives/ for example). 
> (And in the extreme case: multiple CDs in one drive to be changed on
> request a la apt; should be possible in at least C which allows you
> to skip stuff when writing and re-write it later. Which would also
> be useful to concentrate all FTP/HTTP traffic in an
> as-short-as-possible online period.)

Hm, all this could be done, but you'll need to add it to
pseudo-image-kit yourself! :-) 

In true Unix fashion, "jido-file" is just a command line utility which
tries to do one thing well; in this case, work on image template
files. It doesn't contain any networking code. (A second download tool
"jido" will eventually do that, it could completely replace the
pseudo-image-kit.)

This is /roughly/ how it could work:

<insert and mount CD>
find /cdrom -type f \
| jido-file print-matching \
    --files-from=- --template=potato.iso.template \
| (while read filename; do cp $filename old_cd_files/; done)

This scans each file on the CD. If a file's MD5 sum matches one of the
MD5 sums recorded in "potato.iso.template", its name is printed. 
Repeat the above as often as necessary. Next, make the tool print out
any remaining files that still need to be fetched:

jido-file print-missing \
    --template=potato.iso.template --jido=potato.iso.jido \
    --cache=cachefile old_cd_files/* other_interesting_dir/*.deb

This will output any files referenced in "potato.iso.template" that
are not present as command line arguments. The template only
references files via their MD5 sums - the actual filename is
extracted from "potato.iso.jido" (a specially formatted text file). 
The output will look more or less like this:

deb:potato/main/binary-i386/base/package_1.0_i386.deb
nonUS:potato/binary-all/other_1.0_all.deb
...

Now those files need to be downloaded.
Next, build the final iso image:

jido-file make-image \
    --template=potato.iso.template --cache=cachefile --output=potato.iso \
    old_cd_files/* other_interesting_dir/*.deb download_dir/*

Using --cache ensures that all the files given as command line
arguments are not scanned more than once to find out their MD5 sums.


I would really like to concentrate on the jido* tools themselves and
*not* do any work on the pseudo-image-kit, due to limited
bandwidth/disc space (=> no full Debian mirror here) and time (=> want
to spend it on jido). Would it be OK for you to update the kit once
jido-file is in a working state?

All the best,

  Richard

PS: I'm a Debian developer now! B-]
-- 
  __   _
  |_) /|  Richard Atterer     |  CS student at the Technische  |  GPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  888354F7
  ¯ ´` ¯

Attachment: pgp84XOxhx72Q.pgp
Description: PGP signature


Reply to: