I don't believe this is a bug, for the simple fact that when passing the
"-boot-info-table" option, you're instructing mkisofs to insert a boot
information table into the specified boot file.  So, if you instruct mkisofs to
modify a file which is on a read-only filesystem, it's understandable, and
desired, for it to fail.  Things should work as you've described if you remove
the "-boot-info-table" option from the command listed above.

How do I have this decision reviewed?

My recommendation would be that you take the source code to mkisofs, modify the
way that the "-boot-info-table" option works.  Possibly add another option which
would copy the boot file to a temporary location, then modify it to include the
boot table before including it in the ISO image.  Then push these changes
upstream to the mkisofs maintainers.

You're other option is to not include the "-boot-info-table" option when
attempting to create the ISO image.

Either way, still isn't a bug, as it's working as coded.

You have a very strange idea of what constitutes a bug. Programs
always work as coded.

A bug is when a program does not perform to specifications.

Sometimes, the specifications themselves are flawed (as in WEP) and
need to be fixed.

Above all, a program should perform to a reasonable user's reasonable
expectations. I contend that when a program whose purpose is to
transform an input to create an output, modifying that input is not a
reasonable result.

That's quite aside from the operational difficulties this misdesign
can cause.

You didn't answer my question about how to have your decision reviewed.

mkisofs is performing according to specification.  Check the man page:

       -boot-info-table
              Specifies  that  a  56-byte table with information of the CD-ROM
              layout will be patched in at offset 8 in the boot file.  If this
              option  is  given,  the  boot  file  is  modified  in the source
              filesystem, so make sure to make a copy if this file  cannot  be
              easily  regenerated!   See the EL TORITO BOOT INFO TABLE section
              for a description of this table.

In particular "the boot file is modified in the source filesystem . . . "

If your goal is to get an ISO image from the data on the DVD, then you shouldn't
be using mkisofs in the first place.  Instead you would just dd the contents of
the DVD to a file ('dd if=/dev/dvd of=/tmp/DVD.iso bs=2048k'.)

As for reviewing my decision, I did tell you.  Make changes to allow for
inserting the boot info table into a read-only filesystem and submit those
changes upstream to the mkisofs folks.  Otherwise, don't ask mkisofs to modify
the boot file (i.e. don't include the '-boot-info-table' option) or use the 'dd'
solution posted above.

"review your decision" means that someone else, perhaps your manager
or perhaps your QA folk reexamines the issue.

I think my previous post covers your response. I said somethimes the
specifications themselves are wrong. I believe that's the case here.

As for what I'm trying to do, that's not relevant to the question as
to whether the program is performing correctly. In fact, I'm trying to
create a bootable ISO with different content from any I have.

See this script:
ftp://people.redhat.com/ckloiber/mkdvd-rhel3u2.sh

I don't ken all the different options. I do understand that modifying
the inputs is undesirable. I am concerned that running it twice over
the same inputs could cause irrepearable damage were it allowed to
have its way.

And, I'm trying to improve the quality of RHEL even though I likely
will not use it.

mkisofs creates an ISO image of a given directory tree.  If you indicate that
you wish to change one of the files in that directory tree before creating the
ISO image, then it has to be on a read-write filesystem, otherwise it's going to
fail.  Without digging through the source to mkisofs, I can't even tell you if
it's possible to have mkisofs lookaside for a file.

My point is that this is the way that mkisofs is designed to function.  The
quality of RHEL isn't at risk here, as there's "broken" in the way that mkisofs
is performing (either functionally or spec-wise.)  As best as I can tell your
complaint is that if you ask mkisofs to modify a file on a read-only filesystem
as part of creating the ISO image, it fails.  That's not a problem.  If it
didn't fail, then we would have a problem.  If you're worried that running this
stuff twice might damage something, then either don't pass the
"-boot-table-info" option or make a copy of the tree beforehand so that if
something goes south, you still have a prestine copy.

I reviewed my decision with the technical lead for the QA team and he agrees
this isn't a bug, that mkisofs is performing to spec, and that the spec is sound.