Stephen Hahn writes: > (In John's example, star poses no conflict Actually, it does. I don't necessarily agree with him, but Joerg has good reason to want 'star' to be /usr/bin/tar.
> and the /opt/csw variants > are already using the PATH mechanism to resolve conflicts, so I'm not > sure what point is being made. The project team has already conceded > that PATH manipulation is a crude method of selection [jmp-1], but at > this point has nothing better to offer.) John's example falls apart with an excess of GNUish in /usr/bin. With /usr/bin:/opt/csw/bin, he currently gets GNUish versions from blastwave for the things that don't conflict. In the future (with the integration of this project), he no longer gets the blastwave versions, but rather the Solaris-supplied ones. Blastwave becomes invisible for GNU software, and (for him) works only for the larger world of non-FSF-listed software. With /opt/csw/bin:/usr/bin, he gets back his blastwave tools, but with an unwanted side-effect: he ends up missing the Solaris version if something unwanted is dragged in by dependency (which all too often is the case with blastwave). There's no setting that reasonably accomodates external software repositories, other than overuse of 'alias' and private symlink farms. I agree that's just the consequence of where we've already been heading, but, at the same time, I don't think his complaint is unwarranted. -- 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
