On Thu, Oct 24, 2019 at 01:27:44PM +0200, Thomas Schmitt wrote: >Hi, > >i wrote: >> How about mirror checking by SHA256 in grab_md5, before computing the >> MD5 for jigdo ? > >Or you could let libjte internally compute both, SHA256 and MD5, >let it work with SHA256, but store in .jigdo and .template the MD5.
Much cleaner to switch to sha256 here, I think. >(I just checked the API definition. If you can tolerate the function > names libjte_set_md5_path() and libjte_add_md5_demand(), then the > API part used by xorriso will need no change, whatever you decide. > > Not so good looks the API part which re-narrates the way how genisoimage > produced jigdo. Functions libjte_decide_file_jigdo() and > libjte_write_match_record() have MD5 char arrays as parameters. > They'd need to be deprecated and/or replaced by new functions. > I am not aware of any other user of libjte except xorriso. So maybe > just throw out the "Traditional Data File API". I'll take a look at thst shortly. Working on the core jigdo tool first. > What happens to "powerpc" ISOs ? > Will you backport the new JTE to genisoimage ? We haven't made official "powerpc" ISOs in a while, so I'm not sure we need to bother. -- Steve McIntyre, Cambridge, UK. st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.