On Thu, Aug 16, 2007 at 02:29:46PM +0200, Joerg Schilling wrote:
> 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.
If noone says anything, yes. The burden is on the ARC members (and
non-members who bring issues to the attention of the ARC). Yes, this
means that if the ARC is asleep at the switch then bad things can be
let in.
OTOH, _this_ case cannot be said to have been approved with no
discussion.
> > >- Sun ignores the OpenSolaris community.
> >
> > No, it does not. PSARC listened to the arguments of both sides
> > but did not feel your arguments were compelling enough.
>
> 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!
Nonsense, many of us indicated that we understood the compatibility
issue to be about conflicting uses of an option character in different
implementations of tar. The ARC weighted that and evidently did not
consider that a significant problem.
> > 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.
Yes and no.
Anyone can ask to break compatibility with an existing interface in
Solaris (e.g., change the meaning of cp(1)'s -p option, say, or remove
some utility, or whatever). If done within the rules for such changes
the ARC will likely approve, else there had better be a compelling
reason to break compatibility or the ARC will very likely deny.
But that's not the kind of compatibility issue here. The issue isn't
breaking compatibility with tar(1) as it shipped in Solaris 10 (or 8, or
9). The issue is an option conflict with an alternate implementation of
tar(1), and that is NOT in the same ballpark as breaking compatibility
for an interface that has already integrated/shipped.
> > >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}
It should be obvious now that the ARC won't mind such option conflicts,
as long as the utilities have different names/paths.
