Re: Afew words about POSIX and mkisofs

[Bill Davidsen <davidsen@tmr.com>]

Joerg Schilling wrote:

Bill Davidsen <davidsen@tmr.com> wrote:

Bill, discussions would be much easier if you did read the man page for mkisofs
or look at the mkisofs -help output.

  

A few things occur to me about the idea of changing the meaning of -L in 
mkisofs:
1 - mkisofs is not part of the SuS
    

This is not relevant as this my change and there is a set of rules
that should be followed.

  

2 - there are many existing exceptions, the most common being the 
meaning of -L in cc
    

But mkisofs is not cc. Mkisofs is one of the typical applications that
is in the group of commands that deal with symbolic links. 
mkisofs is in the group of commands like ls, chmod, pax and pax is very close
in to mkisofs in it's destination and behavior.

  

3 - this change would break scripts and programs which generate calls to 
mkisofs, potentially thousands of uses. Worse yet, there will be no 
compatible subset of commands which does the right thing on "old" and 
"new" implementations.
    

This is of course complete nonsense, sorry :-(
  

Does that mean you claim that all the scripts and programs which currently use the -L and -f options would continue to work exactly as they do now? Or that in some way not working as intended isn't the same as breaking in your mind.

There is a big difference between what I do and what the hazardeurs from 
the Linux kernel do:

I plan things I do and I allow other people to know about the future behavior
of my programs in advance.

There _definitely_ _is_ a compatible subset in old and new mkisofs versions.
Just read the man page before writing such mail....
  

I have read the old man page, since I don't have the new one only you would say I should read it. I see no option I can use in place of -f or -L which works now and will work identically in the future versions. Please point out the compatible commands I can use for these operations.

In addition: people who now use the outdated options get a warning. 
Depending on the time that will pass until mkisofs 2.02 will be published,
there may even be a time frame when mkisofs will abort with an error message.



  

4 - Joerg is already unhappy about getting complaints about forked 
versions which ship with many distributions, this is bound to generate 
more as things break. And it will probably generate yet more forks.

Suggestion: keep the old command set as default and provide an option to 
switch to POSIX compliant behavior if anyone but Joerg cares to use it. 
    

This is a real bad idea and does not help anybody.

What I do is much better: a smoth planned transition that gives anybody a
long time to accomodate and allows even (although there is no need to do this)
to write shell scripts that work with very old, current and future mkisofs 
versions.
  

The transition is not in any way smooth! One version does one thing, one does another, there is no option (unless you care to point it out) which works now and will work in the future.

You have complained a lot about people creating incompatible versions of your software and not giving them a new name. Have you asked the author of mkisofs, Eric Youngdale, how he feels about your changes? Or do you feel that because you touched it most recently you have the right to mess it up?

You reject this idea because you didn't think of it yourself, hopefully responsible vendors will continue to release versions which continue to work with all the software currently calling mkisofs.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979