Joerg Schilling writes: > > Even as /usr/bin/star, I don't see a reason to overturn 2007/394. > > That case noted that there was _no_ common flag available for the work > > described in section 4.1 of 2007/315 and thus selected '-/' and '-%' > > for its work. > > While it is bad practice not to use a uniform interface for many > tools implementing the same feature (and this is why I did already > send mail for the ls(1) call in June), there is no real conflict for "star". > There is however a conflict with the interfaces that have been build just to > create Solaris compatibility.
Understood. However, those interfaces have not been the subject of any approved or even filed ARC case. The best we have is a discussion of "intent" in a different case that approves integration of 'star' alone. "Intent" by itself doesn't confer any special status or privilege to those features -- which may not in fact ever arrive. In this instance, it's been three years since we saw that old 'star' case, and nothing's happened. > This case breaks compatibility with these interfaces. No. If those interfaces are ever proposed to replace /usr/bin/tar in OpenSolaris (new "projects" in ARC parlance; new cases), then they'll need to conform to the existing expectations *AT THAT TIME* for /usr/bin/tar. The project under discussion here (the one that, as Darren notes, has already been approved and thus that for clarity we shouldn't be discussing here at _all_) forces a change on the implementation if it chooses to migrate to /usr/bin/tar in the future. It hasn't done so, so no force is applied now by this case. However, that's also true if someone else decided to port over GNU tar to become /usr/bin/tar on Solaris. They'd have to explain how they were going to make the command line compatible in doing so. And it's true if someone took the current NetBSD tar and ported that over. And it's true if IBM suddenly decided to open-source AIX and we brought over their /usr/bin/tar. In other words, star is one of a field of possible things that could be used. There is no ARC project describing what future projects may or may not do with /usr/bin/tar options, so we're not bound by that universe of possible replacements. We're bound by history of /usr/bin/tar, consistency with existing system features, and the needs of the project team that is asking for change. An interesting side issue here is that while the ARC is bound to the history embedded in the OpenSolaris sources, the distributors themselves are not so bound. If some distribution wanted to replace /usr/bin/tar with a link to 'star', then have at it. They won't get the benefits of backward compatibility that we're offering, but that's certainly a rational choice they can make. > The correct way of implementing these features in pax would be either by > extending the supported parameter to the -p option or by using the -o option. > When extracting an archive that contains the extensions, -pe should extract > all > available data. If the -o option would be used, it would be something > like: -o xattr I agree that '-p /' would make more sense for pax here. > BTW: Don should know that this arc case is in conflict with the POSIX > philosohy > because it tries to implement functionality in a way that is not aligned with > the way POSIX defines extensions. I agree that '@', '/', 'T', 'p' are just plain backwards for tar itself, which is why I pointed out that I'd rather not have them. There's unforunately a lot of old Sun history here, and ignoring that is difficult. > > Yes, but if that had happened, we would have said: the project > > proposing this new tar implementation came later to the ARC (and into > > OpenSolaris), so make it compatible with the previous projects or > > explain some better way forward. > > OK, the proposal to use -/ came definitely after it did appear in the > interfaces that have been created for compatibility with the Sun commands. No, not as far as we're concerned. Those supposed "interfaces" are not the subject of any ARC case. The only approved case we have is for /usr/sfw/bin/star, and 'star' (as a different program altogether) is free to do whatever it wants, including wierd "FIFO" options. By the logic you're suggesting, we're also bound by every implementation that everyone everywhere has ever made. We need to be omniscient. We're not. We're bound by the projects that the ARC has approved, and by the ones that are in OpenSolaris. We're bound by standards commitments, and by an attempt to stay as true as we can to BSD and SysV roots, and by newer attempts to be compatible with GNUish systems. > > The current 'star' command appears to have some 151 separate options. > > Conflicts seem likely. > > There is a small list, see ~ line 2450 in star.c Now try rationalizing across multiple utilities. That's what the project team did. > The conflicts between /usr/bin/tar and star all have been created by Sun. > The related option have been introduced into star around 1985. The conflicts > did not exist before SunOS-5.x came out. That may be true, but isn't material here. > > And, as Don has correctly noted, it defaults to stripping the leading > > '/' from extracted files, which is helpful for security, but is both a > > POSIX violation and a clearly incompatible behavior. It can't be the > > default tar without changes. > > Don should know that there is no POSIX violation. He did not prove his claim > with a pointer to the POSIX standard, judge yourself whom to believe..... http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html It says nothing about (mis)interpreting an absolute path name as a relative one, or about switching that behavior on or off. (I'd like to see star passed through the validation suite. Perhaps the folks who manage those tests can arrange something.) In any event, regardless of what one thinks about POSIX, the behavior of star is incompatible with the existing /usr/bin/tar. It's incompatible because star made an implementation change (forcing absolute paths to be relative) that historical tar did not have. You can certainly argue that star's behavior is "better." You can't argue that it's compatible. And that's the tip of the iceberg. A case that proposes replacing /usr/bin/tar would have to plumb the depth of these incompatibilities and discuss each one. Fortunately, that's not this case. -- 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
