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

Re: Enlighten me about jigdo ..



On Fri, Nov 14, 2003 at 01:31:05AM +0200, Delian Krustev wrote:
> I wonder what this hype about jigdo is ..

Er - it's not intended to sound like hype, jigdo is just (IMVHO as its
author) better suited for Debian CD image distribution than other
solutions.

> 1.get two files for an image - .jigdo, .template
> 2.download the listed files in the above two from a listed mirror using wget
> 3.run mkisofs to create the image

3 is not quite right; jigdo has no knowledge about the format of CD images
in particular. The template contains descriptions like "this file from the
list must end up at offset xyz in the final image".

> 1. the templates are BIG - as I see from 5 to 20 MB for woody
> (600+ MBs for i386 sid, but I suppose the maintainer of those unofficial
> templates has messed the things up, since this files are as big as an iso)
>  I wonder what this binary data inside them is. What do they need
> except relative file path, e.g. pool/main/a/aalib/aalib-bin_1.4p5-18_i386.deb
> and possibly an md5sum for each file ..

True, the templates shouldn't be so big, this is a result of 1) an "exclude 
list" used by the creation scripts of files which change frequently on the 
server, causing their data to end up in the template, 2) a problem with 
jigdo-file's template generation algorithm itself, which makes it "miss" 
a file sometimes - I finally had an idea for a fix a while ago, haven't 
managed to get around to implementing it.

Hopefully, over time both of these issues will be addressed, leading to 
much smaller template files.

> 2. Most of the mirrors probably provide http because http is an older
> protocol. Jigdo docs says ftp is not efficient and http rocks.

That's my humble opinion, yes. :)

> Ignoring rsync precence(pipelining - no need to establish TCP connection
> for each file, repair of broken downloads .. ) is a really bad idea

An rsync-based scheme (whose design inspired that of jigdo) was used in the
old days, the "pseudo image kit" (PIK). The use of rsync turned out to be
problematic (too much load on the server), so one of the aims of jigdo was
to get rid of rsync. All in all, the PIK worked well, but it didn't scale
to large numbers of parallel downloads.

BTW, one mustn't underestimate the fact that any rsync-based scheme
requires the Debian mirror admins to install rsync servers. Furthermore, 
the complete images must be stored on several servers somewhere...

(Don't get me wrong, I think rsync is really nice - it just isn't 
appropriate for this problem IMHO.)

> 1.use debmirror(over rsync!) to sync packages and files in let's say latest sid
> 2.use rsync to sync the md5sums with a master server so You won't have to search
>   for a trusted mirror.
> 3.use mkisofs to burn your image. Note I currently can't find a way to achieve
>   this last step. What is necessary here is to have a file with the layout
>   of the debian cds to be supplied to mkisofs(or as an input to a script which
>   creates the necessary directory structure) and an isoimage for the bootable cd.
>   Probably some other minor details as cdlabels .. The cdlayout file is an ascii
>   text file ofcourse and could also be rsynced. The jigdo-file(1) says you need 
>   the iso image to create the .template and .jigdo files, so I suppose the 
>   mentioned layout is actually used by the people making the iso-s ..

I faced the same problem as you in 3. - it is an absolute requirement for 
Debian CDs that the users end up with a bit-exact copy of the original 
image, so IMO creating it with mkisofs is not an option. :-/

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯



Reply to: