From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041002 Description of problem: Jigsaw Download, or short jigdo, is an intelligent tool that can be used on the pieces of any chopped-up big file to create a special "template" file which makes reassembly of the file very easy for users who only have the pieces. What makes jigdo special is that there are no restrictions on what offsets/sizes the individual pieces have in the original big image. This makes the program very well suited for distributing CD/DVD images (or large zip/tar archives) because you can put the files on the CD on an FTP server - when jigdo is presented the files along with the template you generated, it is able to recreate the CD image. There is no worry about the generated isos not being "official" because jigdo uses MD5 to guarantee that the generated file is the same as the original file used to create the template. There would be many benefits to Red Hat servers, mirror servers, and end users if template files would be provided of all the iso images. 1. If desired, Red Hat could choose to only distribute release trees and jigdo templates instead of full CD and DVD iso images. This would immediately save at least 2/3 the needed space for a release on the Red Hat and mirror servers, with the potential to save even more if hardlinking across architectures is used (no more need to have mostly duplicate SRPMS iso images for i386 and x86_64). Anyone could easily recreate the iso images with jigdo, including mirrors if they wish to provide them for download. 2. Even if iso images are still provided, mirrors could more quickly and more efficiently sync up by using rsync against the tree. During a release sync, mirrors could link RC trees or the rawhide tree to the release tree followed by an rsync from the master server, which could save bandwidth and time by only transferring changed files. Rsyncing iso images do not gain this advantage, and would be unnessary since jigdo could recreate the identical official iso images locally. 3. Different kinds of iso images could be provided, without ballooning up the space requirements on the master server and mirrors, and without overloading the already stressed internet pipes during mirror syncing and after release. For example, jigdo templates could be provided for binary and source CD iso images, binary and source DVD iso images, and perhaps even a combined source+binary DVD image for those who wish to burn to larger, more expensive dual-layer DVD media. 4. Media conversion. One only needs a set of packages (or release tree) plus a jigdo template file in order to recreate a big image. In this way, someone who already has the CD's can make a DVD or vice versa without redownloading the mostly redundant information just to get a DVD image. 5. An intelligent mirror/download tool could be developed (there may already be one) that could pick bits and pieces of the distro from different mirror servers (each RPM file download for example). In this way, jigdo gains many of the advantages of a "swarm" protocol, like BitTorrent, but it uses standard FTP/HTTP, which is not firewalled in many networks like BitTorrent often is. The URL points to the fedora.us work in progress package of jigdo.
It would be a good idea for someone to package it in Fedora Extras repository. If you are interested kindly look into http://fedoraproject.org/wiki/Extras
Redhat should seriously consider using jigdo for file distribution. jigdo was proven successful with Debian. It's a win-win situation for the Fedora community and the bug reported thoroughly explained the reasons. Jigdo is already in the Extras repo. This bug should be reopened with Fedora 8 as a target release implementation.
I think this is too late for Fedora 8, but I'll reopen and target for Fedora 9.
http://fedoraproject.org/wiki/Features/JigdoRelease Also, we are working on pyjigdo, python based jigdo.
Fedora Unity went to distributing our re-spins(origional media +updates) with jigdo as of F7. We are very happy with Jigdo as a very low bandwith solution for distributing the respins.
Rel-Eng is doing this now, right? Closing...