Nicolas Williams wrote:
> On Tue, Jan 30, 2007 at 10:38:29AM -0800, John Plocher wrote:
>> B) How does this address the issue of "the bits delivered by Sun
>> are stale and I'd like to refresh them?"
> The easy way to deal with this is this:
>
> - the OpenSolaris community (including ARCs) is the authority for what
> goes into /usr/gnu, just as with /usr/bin and what not
The ARCs work best when managing the changes being made to a consolidation,
and not in managing product construction details. In this case, the defacto
owner of the GNU consolidation is the FSF, *not* OpenSolaris. Nothing we
do here will prevent change from happening to those bits, nor keep our
users from wanting those changes on their systems.
All we can do is get in the way. So the question is how to minimize the
costs of being in the way and/or to make the benefits accrued be worth it.
>
> - customers who want the latest and greatest should do what they've
> always done: either wait for us to deliver it in the usual places, or
> install it themselves in locations that they are authoritative for
> (e.g., /usr/local, /opt/whatever).
The disconnect here is semantic:
Before this proposal, it was possible to construct a PATH that provided
Solaris/Posix/SUS utilities first,
"latest and greatest" GNU utilities second.
After this proposal, it will no longer be possible to do so because the
namespace used by the "latest and greatest" will be overridden by names found
in /usr/bin.
If I were to put the latest and greatest directory in front of /usr/bin
in my PATH, *those* bits would collide with the POSIX/SUS namespace.
Lose/Lose both ways.
The only way this proposal "works" is if the GNU bits are treated as their
own consolidation, and that consolidation can be updated and installed
by whomever needs it. All other options seem to result in replicated
variant copies of the bits...
-John
