[Debburn-devel] schilyutils upload

[Steve McIntyre]

On Wed, Aug 12, 2009 at 04:25:54PM +0200, Thomas Schmitt wrote:
>Hi,
>
>Steve McIntyre wrote:
>> ... libburnnia and friends ...
>> I have some porting
>> work that I need to do to make that happen usefully (e.g. the code in
>> genisoimage to generate jigdo files),i
>
>I have read http://atterer.net/jigdo/ and
>man genisoimage, especially JIGDO NOTES.
>If i understand it right then the task
>of genisoimage is to read the -md5-list,
>and to generate -jigdo-jigdo and
>-jigdo-template along with the ISO image.

Yup, that's correct.

>> and I'm struggling to find the tuits.
>
>Our libburnia documentation or the one of
>jigdo ?

tuits -> "round tuits" -> "around to it" -> time.

Sorry, silly en_GB slang...

I can find what I need to do the job, it's just the time to dig into
it.

>For telling where to implement the jigdo
>features i would need some more info about
>the task of the ISO 9660 formatter with jigdo.
>- What goes in ?
>- What goes out and how is it computed ?
>- What side effects on the emerging ISO image ?
>- How is the relation to the pathspecs given as
>  normal genisoimage arguments ?

The output jigdo file(s) are simply another representation of the
contents of the ISO image. The image itself is identical with/without
the jigdo generation options. The data is organised such that:

 * contents of files that we know about (i.e. listed in the -md5-list)
   are referenced by checksum in the .template file instead of being
   included directly. The md5->filename lookup information is stored
   in the .jigdo file.

 * any other data that does not match known files is compressed and
   stored directly in the .template file (e.g. filesystem headers,
   directories, padding)

>From these two files and an archive of the files used, it's possible
to recreate the output ISO image very cheaply. For people downloading
Debian CDs and DVDs, it's a convenient way to potentially save on a
lot of bandwidth.

>The implementation candidates would be
>- libisofs
>- xorriso
>Within both we would have to identify the
>hooks where to attach jigdo functions to
>the existing code.
>Both are designed as collection of independent
>API functions. Nevertheless the image generation
>code of libisofs is quite complex. Best would
>be to perform all jigdo operations before
>the image stream gets produced.

I hooked into mkisofs/genisoimage by simply targetting all the places
that write to the output ISO image, and adding a parallel call to the
jigdo code there. Oh, and of course some startup and shutdown code
too. Not too difficult if the internals are clean and easy to follow
(as I hope)... :-)

>We do not support UDF yet.  Would that be a problem ?

Not for me, no. I'm more interested in using/adding hfs hybrid code to
support Macs, frankly.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews