[CentOS-devel] Jigdoes of CentOS 4.4 and 5.0 i386/x86_64 CD/DVD available.

Maciej Żenczykowski

zenczykowski at gmail.com
Thu Apr 19 00:42:13 UTC 2007


Regenerated and uploaded the new jigdoes, old ones renamed with a trailing '_'.

CentOS-5.0-i386-bin-1of6.jigdo
CentOS-5.0-i386-bin-1of6.template
CentOS-5.0-i386-bin-DVD.jigdo
CentOS-5.0-i386-bin-DVD.template
CentOS-5.0-x86_64-bin-1of7.jigdo
CentOS-5.0-x86_64-bin-1of7.template
CentOS-5.0-x86_64-bin-DVD.jigdo
CentOS-5.0-x86_64-bin-DVD.template
md5sum.txt
sha1sum.txt

(basically both the first CD and the DVD contain the release notes, so
they all needed a rebuild, I verified all the others didn't
change/still work (at least on my local mirror)).

> They shouldn't. These seem to have changed because of the charset fuckup
> with the release notes on the ISOs.

Hmm.  Well, in the future we should either not make such changes (I'm
assuming we want to keep valid jigdoes around) or we'll have to
regenerate the jigdo/template files in such a situation.  I think
sticking the new fixed files under a different name would also be a
valid solution (you can add new files, what you can't do is you can't
change existing files required by jigdo).  We could also possibly run
jigdo with a minimum file size requirement closer to 200KB which would
allow changes to the smaller (ie. text) files.

However I would vote for keeping the os tree totally frozen from the
point of release.

Although increasing the min file size would possibly also with only a
slight template file size increase reduce the number of files needing
downloading...

Here's a list of the current number of external (ie. in mirror) files
in each jigdo/template:
CentOS-4.4-SRPMS-src1of4.jigdo: 204
CentOS-4.4-SRPMS-src2of4.jigdo: 205
CentOS-4.4-SRPMS-src3of4.jigdo: 208
CentOS-4.4-SRPMS-src4of4.jigdo: 208
CentOS-4.4-i386-ServerCD.jigdo: 606
CentOS-4.4-i386-bin1of4.jigdo: 2138
CentOS-4.4-i386-bin2of4.jigdo: 255
CentOS-4.4-i386-bin3of4.jigdo: 381
CentOS-4.4-i386-bin4of4.jigdo: 340
CentOS-4.4-i386-binDVD.jigdo: 3104
CentOS-4.4-x86_64-bin1of4.jigdo: 2368
CentOS-4.4-x86_64-bin2of4.jigdo: 256
CentOS-4.4-x86_64-bin3of4.jigdo: 411
CentOS-4.4-x86_64-bin4of4.jigdo: 474
CentOS-4.4-x86_64-binDVD.jigdo: 3508
CentOS-5.0-i386-bin-1of6.jigdo: 559
CentOS-5.0-i386-bin-2of6.jigdo: 418
CentOS-5.0-i386-bin-3of6.jigdo: 421
CentOS-5.0-i386-bin-4of6.jigdo: 357
CentOS-5.0-i386-bin-5of6.jigdo: 422
CentOS-5.0-i386-bin-6of6.jigdo: 214
CentOS-5.0-i386-bin-DVD.jigdo: 2386
CentOS-5.0-x86_64-bin-1of7.jigdo: 575
CentOS-5.0-x86_64-bin-2of7.jigdo: 555
CentOS-5.0-x86_64-bin-3of7.jigdo: 520
CentOS-5.0-x86_64-bin-4of7.jigdo: 398
CentOS-5.0-x86_64-bin-5of7.jigdo: 492
CentOS-5.0-x86_64-bin-6of7.jigdo: 348
CentOS-5.0-x86_64-bin-7of7.jigdo: 219
CentOS-5.0-x86_64-bin-DVD.jigdo: 3100

To me it doesn't look to bad, seems average file size is easily above
1MB, so the number of required files (ie. connection
establishment/handshake/etc) shouldn't drastically impact performance.

(ie. downloading via jigdo shouldn't be much slower than downloading
the iso directly - assuming you're downloading from the same mirror).

Jigdo also has the added benefit of reducing the amount of data
mirrors need to sync, and allowing us to release stuff like rolled up
update cds with almost no mirror space/bandwidth overhead (same thing
for anything else that uses in-tree files, live ServerCD's, but not
LiveCD's [which are totally recompressed and thus have no common parts
to the os tree].

> On another note: I was able to rebuild all other x86_64 CD isos and they
> do have the same checksums as the ISOs on the mirrors.

Yes :) I did verify this at home.

> And I asked dag to rebuild jigdo-0.7.3 for rpmforge, so it will be
> available for CentOS 5 also.

Cool.

> More testing from me in the next few days, I have to go through the
> documentation first and that needs a little time.

What we need to figure out is a better way to specify the source
mirror, possibly hack around in the jigdo-lite script.  It might also
make sense to see if we can improve (parallelize) jigdo-lite download
performance to make it work better on bigger pipes (and possibly not
require quite so much temporary space).



More information about the CentOS-devel mailing list