>Date: Thu, 09 Nov 2006 15:34:37 +0000 >From: Darren J Moffat <Darren.Moffat at Sun.COM> > >Don Cragun wrote: >> The project team is not trying to set precedent by doing this, but I >> would expect it to be used frequently in similar cases to avoid >> backwards compatibility problems. > >Is there any reason why we shouldn't set precedent here ?
I don't think we need a precedent to use due diligence. If a project team or any review committee (including PSARC) believes that moving or removing a utility will break applications, the project team either needs to install a link (hard or symbolic) or find and fix applications that may be affected by the change. This just seems to me to be common sense. > >Given what you said about standards compliant applications being allowed >to use the full path I think that says that we always want these >symlinks when we unify a /usr/bin and /usr/xpg?/bin utility otherwise >things will break. If we end up removing a /usr/xpg*/bin utility due to a fix required by an interpretation request (which intentionally changes behavior), a project team may decide not to install a symlink. (I'm not concerned about any precedent if this issue comes up; any project that does this would be granted an exception if needed. I'm just saying that "always" may be too strong.) > >In case it isn't clear I think this case should be setting precedent. Is this a formal request to turn this into a fast track to set a precedent? (If I remember correctly, a self-reviewed case can't set a precedent.) - Don > >-- >Darren J Moffat
