Jigdo [was re: fc4t2 a little early]

[Michael A. Peters]

On 04/10/2005 09:45:17 PM, seth vidal wrote:
> 
> > which is yet another readon for Fedora to adopt jigdo - the respun
> iso
> > could be distributed via jigdo, making very little downloading
> required
> > for those who had issues to be able to test the respin and see if
> they
> > are resolved.
> >
> 
> Do me a favor.
> Everytime someone mentions isos, you mention jigdo. However, what
> I've
> never seen you do is link to jigdo-ized releases of fedora.
> 
> try it sometime.
> 
> do a jigdo from fc4t1 to fc4t2 isos.
> 
> I wanna see what sort of bandwidth saving is possible. Rather than
> just
> take your word and jigdo's website word for it.
> 
> Let's get some numbers, shall we?

"Every time" is a little bit of an exageration, but yes - I confess, I  
pimp jigdo - it saves me a lot of bandwidth with Debian ISO's.

With respect to a FC4T1 to FC4T2 jigdo update, there may be some  
bandwidth savings, but it probably would not be much because a lot of  
packages will have changed between the two respective ISO's.

Tiniest change in a package, and jigdo wants an entire new package.

Where jigdo will save bandwidth - if the test releases were released  
via jigdo, I could tell it to scan my mirror of rawhide packages, and  
it would only need to downloads files needed for the iso that were not  
in my rawhide mirror.

With FC4T1 there were 3 major bugs on release -

1) gdm
2) firstboot
3) disk integrity check

With jigdo, it would have been possible to release a FC4T1.a that had  
those fixed, since not many files on the iso's would need to be changed  
to fix at least the first two issues, getting a fixed iso would be as  
simple as mounting your FC4Test1 dvd iso, pointing jigdo-liste at the  
FC4Test1.a jigdo file, and telling it to scan your mounted FC4Test1  
dvd.

The files that were identical between the two would not need to be  
redownloaded to make the new iso file, because jigdo-lite would find  
them on the mounted DVD.

Where jigdo also saves bandwidth is the creation of the test releases  
from people who have local rawhide mirrors. They can have jigdo-lite  
scan their rawhide mirror, and it can create the iso files using mostly  
packages from the local rawhide mirror - only needing to fetch those  
files from the fedora server that were not present in the local rawhide  
mirror.

Jigdo's biggest advantage however is that is saves on mirror disk  
space, and that I believe was the original reason Debian moved to using  
it.

If you have a full mirror of fedora, you have every single rpm 3 times  
(one for download outside the images, one in DVD image, one in CD  
image) - and noarch rpm's, you have many many times.

With jigdo, a lot of mirrors could choose not to mirror the iso images  
- but instead only mirror the packages and jigdo files needed to create  
CD's/DVD's - and still be able to provide CDs/DVDs to their users  
without needing the disk space of all of the ISO images. I imagine this  
would also greatly reduce the bandwidth needed before a release to  
populate the mirrors.

The bandwidth jigdo would save going from FC4T1 to FC4T2 can be  
calculated, look at the size of files that identical between the two.  
Tests aren't needed, if jigdo-lite has scanned a file it needs for the  
image it is creating, it uses that file - and doesn't download it.

It's probably not that great between FC4T1 and FC4T2 because a large  
number of packages have been updated. Where the savings would be -  
would be creating iso's for people who already have lots of current  
rawhide packages (IE have jigdo-lite scan /var/cache/yum/extras- 
development/ ) and the desired (but currently non-existant) respins of  
test iso's to fix issues that are found within 24 hours of a release.

-- 
Michael A. Peters
http://mpeters.us/