On Thu, Oct 21, 2004 at 02:28:27PM +0100, Steve McIntyre wrote: > Richard Atterer writes: > >(Of course, at the expense of outputting images with a wrong (i.e. zero) > >image md5sum, you can go faster...) > > Yes. I was discussing this with some people last night. The MD5 step > is the hard bit. If we are prepared to lose the MD5 of the entire > image (or use another checksum algorithm that can be updated just > using existing checksums of the parts in the image) then we could > probably generate jigdo files on the fly in _seconds_ simply by using > the data already in the Packages files. We'd need to make a few tweaks > to the CD layout, but it's doable if we want it.
I'm not sure if it's worth it to switch to another type of checksum: The template data already has checksums for the individual files, and the remaining compressed data in the template is protected by the compression's checksum. (An RsyncSum64 would fit your description; if you have the checksum for two chunks of data, then calculating the checksum for the concatenated data is very cheap.) I think that ATM jigdo does not recognize a zero md5sum as special, it'll report a checksum mismatch. Should I change that? IMHO official images should include a valid image md5sum, though. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
