Joerg Schilling writes: > James Carlson <james.d.carlson at Sun.COM> wrote: > > I think you mean to say that you believe that the ARC members are > > either deliberately or ignorantly _precluding_ the option of replacing > > pax and other things by star in the future. > > > > This is not true. We do understand the nature of this > > incompatibility. We're not fools. And there is no attempt or intent > > to preclude _any_ future project. > > Why then do you try to include new incompatible options that prevent to > implement the option of replacing the programs?
I didn't try to include anything. I don't know why you're confusing me with the project team or with the ARC itself. Nor do I believe that the project team proposing this change is attempting to prevent any such thing. This project (like many that have preceded it) forces a requirement onto such a future replacement project. It does _not_ prevent such a project. > > The nature of the incompatibility is that, when invoked as > > /usr/bin/tar or /usr/bin/pax, the 'star' implementation will be forced > > to adopt the command line behavior of those older tools, the file > > formats, and the documented behaviors. That requirement for backward > > compatibility extends even to the options and features that the author > > of star dislikes, such as the older '-@' and the new '-/' option. > > This is not true: Yes, it is true, because this is the nature of backward compatibility. It's one of the most important things we (in the ARC) enforce. You won't get to pass "go" without it. > Even though the way of using -@ is questionable, the main problem with the > implementation of the functionality is that it is based on deprecated methods > from POSIX.1-1988 instead of being based on portable and vendor tagged > POSIX.1-2001 methods. In evaluating compatible change in OpenSolaris, that doesn't actually matter. You may be right that it's poorly designed. You may be right that a suitable "expert" would have done it differently. However, none of that matters to a user who is trying to extract an archive created by an older system using this existing format, or create an archive to transfer to such a system. What matters in those cases is compatibility. > philosophy. The fact that Sun did not update this preliminary implementation > by a fully POSIX.1-2001 based extended tar format did throw Sun's tar back to > the stoneage. All additions that have been implemented in sun tar lateron, That may be true. It's also irrelevant. > > When invoked as 'star', the utility may do as it likes. It needn't > > support anything the other existing utilities do. But when invoked as > > /usr/bin/tar, that's when backward compatibility becomes important. > > This was implemented, but this kind of compatibility will be destroyed by > accepting the current ARC case. Nonsense. It forces _more_ work onto such a future project, but it does _not_ prevent it. You've failed to explain how this case actually _prevents_ anything from occurring in the future. > Do you know the difference between the term "star" and the term "tar"? No, of course not. Like most of the people on this list, I live to be insulted. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
