Kyle McDonald writes:
> At least not until these packages stop using compile-time options. Sun
> can ship uptodate versions, but unless they are also going to ship every
> permutation of compile time options, it won't work.
>
> Also sites don't like to move to a new version till they do so on every
> platform. So even if Sun was first to every new version, Sun would need
> to also include the option to install any older version?
>
> Clearly both of these are impossible, so the need to override this stuff
> remains.
Right. And you have several possible solutions, depending on
circumstances:
- Don't install the packages you (for whatever reason) don't like.
Build from source instead.
- Build from source, install in some other location, and prefix that
on your path.
- Build your own versions of the Sun-supplied packages using the
freely available source and install those instead. (In effect:
become a distributor.)
- Create a forest of symlinks and/or command aliases as needed to
override the path.
This case isn't the "serendipitous discovery" case, and essentially
all of the issues you're talking about fall out of that
previously-decided case. If you feel that case was wrongly-decided,
then please do open a new one giving a better answer, or appeal that
decision.
This project is just following in those already decided (and indeed
already followed) footsteps, at least with regard to /usr/bin.
The novel bit is in the use of /usr/gnu.
--
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
