Re: Migrations to xorriso

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> I'm thinking to allow passing arbitrary options to xorriso by just
> putting it on command line.
> Do you recommend to switching to native xorriso interface?

There are differences how file names without "="
are handled.
xorriso maps /my/dir to /my/dir.
xorriso -as mkisofs maps /my/dir to /dir.
Since i expect scripts to operate grub-mkrescue,
i would be cautious with this change.

Lifting the ban on -*) would allow the user to
switch to xorriso CLI by giving argument "--".
grub-mkrescue would just have to put any unknown
argument into ${source}.
E.g.
  grub-mkrescue \
      --output=result.iso \
      -no-pad /my/os /my/payload \
      -- \
      -set_filter_r --zisofs /payload --

(I imagine that /os would be able to read the
 zisofs compressed /payload after booting.)


> This size saving matters only for floppies.
> Perhaps we should add an
> option --pcfloppy which will additionally
> disable all other platforms.

Sounds like a good idea.


> Also I find the way of configuring with "| cat >" quite ugly. Is there a
> reason not to have an option for this behaviour?

It happens automatically deep under xorriso.
xorriso sees the output file as libburn drive.
libburn recognizes the file type and chooses
an appropriate drive model: overwriteable
or sequential. xorriso then reacts on this
choice.

I could introduce an option. But one would then
have to wait for the next xorriso release to
become available in Debian.
So for now it seems better to use cat, if a
thorough diet is desired.


> > internationalization
> [...] gettext [...] 
> But the hic is if xorriso uses any like
> printf("Device %s is %s.", devname, valid ? "valid" : "invalid");

I would have to review the code for this.
xorriso -report_about HINT will not issue much
entertaining messages anyway.
(In general i believe it helps world peace if
 everybody learns some english.)


Seth Goldberg wrote:
> Solaris uses a ISO9660 filesystem image with individual
> compressed files, [...]
> The value to grub2, though, is unknown.

Compression seems appealing for CD images
with large payload or for old USB sticks.
Since the files of GRUB are small, one can
restrict compression to the other files of
the image, so that GRUB is not affected.

zisofs has the advantage to allow random
access inside the compressed files. User space
does not have to be aware of it. I have even
experienced better read speed on slow media.
The compression ratio is slightly inferior to
plain gzip, though.


Have a nice day :)

Thomas