>> One notable exception is the proposal calls out that /usr/gnu is a
>> fully populated - namely, even if there is no conflicting name in
>> /usr/bin, there is still a component in /usr/gnu/bin (either
>> /usr/bin/prog symlinks to /usr/gnu/bin/prog or vice-versa.) This is
>> different from /usr/xpg[46] which are sparse directories and only
>> contain conflicting components.
>
> That's not how I read this:
>
>> In the case that an environment composed of the non-conflicting GNU
>> components plus the historical variants is desired,
>>
>> PATH=/usr/bin:...
It's true in that case that /usr/bin will provide an environment of the
non-conflicting GNU components plus the legacy. But I believe the
intent of the proposal was to also link in those non-conflicting
components under /usr/gnu/bin as well. But I may very well be confused
as there was a flurry of discussion around this point on the
OpenSolaris sfwnv-discuss list and perhaps that didn't get added to the
proposal. I believe the relevant paragraph from the proposal is
Extended discussion led to an aesthetic preference for a complete
environment, in which all components of the installed upstream
package were in their normal locations within /usr/gnu. (We return
to this point briefly in Section 2.5.)
Although an environment could be further modified to be a full
alternative commands environment, that aspect is left to a future
case.
Stephen, is the intent for this case that non-conflicting GNU programs
live both in /usr/bin/myprog and /usr/gnu/bin/myprog or just the
former? Personally, I prefer the /usr/xpg[46] approach but I thought
others were arguing for both name-spaces.
dsc
