>Casper.Dik at sun.com wrote:
>
>> >So let us conclude:
>> >
>> >- There have been no compelling arguments from the people who
>> > filed the ARC case, proving that there is is no better way
>> > to implement this feature.
>>
>> There is no need to provide such an argument.
>
>So the ARC commitee will approve anything without discussion?
>This looks extremely bad.
Do I really need to spell this out?
There is no need to provide an argument that THERE IS NO BETTER WAY.
Clearly it is stupid to require project teams to proof that their
solution is the best solution. We couldn't get any work done that
way ever again.
The ARC is to make sure that solutions are not stupid and this case
easily passes that test.
>
>> >- Sun no longer cares about long term interface stabiliy.
>>
>> Joerg, please don't make sweeping generlizations like that. As Joe
>> explained, in this particular case there is no departure from an
>> existing interface.
>
>I did explain why this is true. If you like to respond, please give arguments.
James already explained this in much greater detail; the summary of which
is:
"star's current command line implementation, behaviour, etc, is
COMPLETELY IRRELEVANT to OpenSolaris ARC cases".
Joerg, your arguments have been heard but they have convinced no-one that
the "/" option is bad.
>I did not yet see any argument from a Sun person that verified that this person
>did understand the problem. Let us have a duscussion _after_ I see that there
>is a will to understand the problem and to look at star to understand the star
>philisophy. This did not happen yet!
Joerg, you are being extremely offensive by continuing to claim that
"those who do not agree with me do not understand the problem".
That is NOT an argument you can use in a discussion.
>> There is NO-ONE who is allowed to VETO decisions; that would not
>> give a workable situation.
>
>So anyone is able to introduce incompatibility in OpenSolaris?
>Then something needs to be changed.
Sigh. No. Please re-read what I wrote.
>> >I hope that the man pages for tar(1), cpio(1) and pax(1) will get a hint
>> >that
>> >the option -/ may in future be replaced by an option with different name
>> >without notice.
>>
>> That is extremely unlikely to happen. If star(1) is integrated as
>> tar/cpio/pax
>> then it will need to implement the compatibility option "/" as it is
>> implemented now. "star" being option incompatible with tar anyway is
>> free to implement the "/" option whichever way it pleases.
>
>OK, if star is really free to do so, Sun would need to mention that there is
>no
>grant for stability with the currently intended meaning for -/ in
>/usr/bin/{tar!cpio!pax}
No, again you misinterpret what I wrote.
Suppose we have an implementation of tar/cpio/pax and we call this
implementation STAR.
When this implementation is invoked as "tar/cpio/pax" from /usr/bin
it MUST behave exactly compatible with the current versions.
If this implementation is invoked as "star" it is free to do as it
pleases.
Casper
