Nicolas Williams writes: > I think J?rg has effectively been arguing (2), that given the existence > of a third party utility that could replace a Solaris one, then the ARC > shouldn't approve cases that create conflicts with such a third party > utility.
Actually, I think his objection is more subtle than that. The objection is that 'star' is designed to be used on Solaris systems. It's been around for a "long time" and can be used by _customers_ to replace /usr/bin/tar on a system, and probably has been used that way. Given that, he feels the ARC should protect that usage by refusing to adopt changes to the base /usr/bin/tar that are at odds with this add-on tar variant. Users who replace /usr/bin/tar with star _today_ are exposed to danger because of a project like the one under discussion. The point of disagreement is around how binding this relationship really is. He seems to feel that the passage of time and his intent to support Solaris are enough to create a strong reason for the ARC to protect his space. I don't agree with this. Historically, we have looked to the evolution of the utilities in question, known dependencies with consumers of the interfaces, the standards, and even other operating systems. We haven't paid much attention to "replacement" schemes, even if well-intentioned. Users who do this are hacking their systems and are at best relying on the alternate vendor's ability to deliver compatibility, not Sun's, because _we_ own /usr/bin. Anything else showing up there doesn't belong. My point of view is that until there's an ARC case proposing replacement of /usr/bin/tar with this 'star' variant, we have no controlling precedent other than POSIX and the Sun historical tar implementation. 'Star' is no more significant here than any other home-directory experiment. -- 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
