> How comfortable is the Guix patching system ? :))

Very comfortable.  But we'd like not to diverge from upstream too much.
We are all in this together, so I'd like upstream to eventually converge on
a solution.  I'm fine with carrying a patch if it's coordinated by people with
knowledge about the matter at hand.  For multiple projects, we already carry
patches while they are being actively reviewed upstream in order to fix bugs.

If the problem is not too bad, I'd like the change to take the normal path
instead of us interfering with upstream.  But here, you *are* upstream so
it's really up to you whether we should patch xorriso or not.

As for people testing possible avenues by patches in Guix, that's easy to do.

> This is quite contrary to the expectations of partition editors, though.
> I deem this EFI's behavior a much clearer bug than the Macbook EFI's.
> So i stay with my proposal of native xorriso command
>   -boot_image any iso_mbr_part_type=0x83
> or mkisofs emulation option
>   -iso_mbr_part_type 0x83
> 
> (To my knowledge, the Guix xorriso run switches from mkisofs emulation
>  to native commands by "--". So -boot_image would be the one to use
>  if it gets appended to the other arguments.)
> 
> 
> > Add an option to “guix system disk-image” to select which
> > grub-mkrescue-sed.sh environment variables to enable?  
> 
> This would be great.

Since grub-mkrescue-sed.sh is part of xorriso, it's easy to get it
to where it needs to be (gnu/build/vm.scm) from where xorriso is
refererred to (gnu/system/vm.scm).  (Just pass the package as argument)
I can do that part.

The patches would then go into the xorriso package definition we carry
(gnu/packages/cdrom.scm) and modify grub-mkrescue-sed.sh in its output
(the patching part would require no Guile knowledge, they are just
".patch" files we distribute and automatically apply).

I'm not sure about amending "guix system disk-image" by options that
aren't really end user options, but I guess it can't be helped.

Basically they would just be something that we'd tell users which
have problems booting the Guix iso to use.  Even that is a lot to ask
from normal users--building a new installer ISO for the sake of
installing Guix.

> (I was brought up with HP BASIC and never was able to solve the Lisp
>  puzzles in german magazine Bild der Wissenschaft of the 1980s.
>  So i cannot help much with translating the usage gestures or even
>  the script itself from shell to Guile.)

Oh, I see.  It's fine if it's in a shell script.

We aren't opposed to shell scripts--sometimes (in initrd etc) we already have
Guile there and don't want to bloat the image by shells and shell utils.

But in this case, we would be patching the iso generator which requires
a lot of the system anyway, so who cares if we pull in the shell and 20
small utils?

Also, we try very hard to keep packages modular.

But if no care is taken, shell scripts take stuff from the global environment
and thus are very difficult to predict and isolate for modularity.

Think of what happens when someone replaces the "test" binary
in $PATH, or "sed".  It will unintentionally potentially completely
change the output depending on what the user has installed (it's definitely
not what the user intended to happen).

As a first countermeasure, we build inside isolated build containers, which
makes the problem less bad.  But then grub-mkrescue will invoke
grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up
as the sed to use?

(For that matter, think of what happens when another xorriso is somewhere
in $PATH and we use --xorriso=.../grub-mkrescue-sed.sh).  (I see that
you already take care to use a "closer" xorriso--but these kind of problems
pop up in shell scripts for almost every term used in there.  It's kinda
difficult to get them to behave)

What's more, shell scripts don't fail on error.  For example in
grub-mkrescue-sed.sh there's no "-e" in the shebang, which means that if
some command in there has an error, the shell will happily continue anyway.
I'm not blaming you, that's just the culture with shell scripts.

Even with "-e", if a command in a pipeline fails, it will sometimes still
not fail the shell script.  For that, you need "set -o pipefail" which is
a bash feature and not necessarily available on other shells (dash etc).

Guile, on the other hand, will just fail the script on error (usually).