Casper.Dik at sun.com wrote:
>
> >This is if course incorrect: When _you_ chose to add -/ to Sun's current
> >tar/cpio/pax implementation, you plan to boycott a possible future
> >integration
> >of an star based implemention to replace the old Sun programs. This is
> >because
> >_you_ chose to deliberately add an incompatible interface.
>
> Please do not use words like "boycott" as they convey something which
> clearly does not match the intention of the people integrating the
> software.
Well, the habbit I see from some of the people here creates this impression.
Feel free to correct this impression.
> Secondly, I don't think your statement is factual correct.
>
> Stepping over the fact that there is not even an ARC case proposing
> the replacement of the above mentioned commands with star, it is
> clearly possible to both have this option *and* later replace the
> commands with an star based implementation as long as there is
> no requirement that the star source code does not change.
Did you read ARC Case 2004/480?
Did you notice that it contains exactly a discusssion about this option?
Well, the list of incompatiblities from 2004/480 is not correct, there are much
less differences than 2004/480 would make you assume.
> Even before this case, the requirement for such a replacement are
> fairly simple:
>
> - star will need to be able to read AND WRITE[1] all Solaris
> compatible formats.
It does this for all formats that are ducumented!
Feel free to provide a documentation for the missing formats.
If we aggree that you provide documentation and that none of the sun tar
enhancement that has been introduced after June 16th 2004 (using deprecated
methods) needs to be supported but only the functionality needs to be present,
this wouls be easy to achieve.
The reason why I believe that there is some kind of boycott is that Sun
did introduce new functionality using outdated methods without even trying to
discuss a better solution.
> - star, when called as the replacement programs pax/cpio/tar
> will need to behave *exactly* like the current Sun implementations
> (they may have additional options but the existing options must
> be preserved and work compatibly)
>
> Both of these requirements will require work for star.
Please try ti inform yourself on the star prject. Let us continue the
discussion after you did prove that you did understand the work that has
already been don for this ans how it has been done.
> I think PSARC is well aware that the second point is affected by
> PSARC 2007/459. Yet, having weighted the arguments pro and con they
> do not see this as being an undue burden, a hurdle which cannot
> be overcome. It is, afterall, just a simple matter of programming.
None os the "arguments" seen from Sun people for 2007/459 did verify that
the problem was understood. Let us continue this discussion after something did
change.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
