Joerg Schilling wrote:
> Kyle McDonald <[EMAIL PROTECTED]> wrote:
>
>
>>> Could you please explain why some people including you try to "convert"
>>> a general problem (that I mentioned some time ago) into a personal problem?
>>>
>>>
>>>
>> I'm not making it personal. I don't see how you read that into what I
>> wrote. I was just applying what I understand (now) the process to be to
>> the example someone else asked about.
>>
>
> Then I must have missunderstood you - sorry.
>
>
>>> It seems that this is just to pretend it is less important than it really
>>> is.
>>>
>>> The general problem is that conflicting names cannot be in /usr/bin in
>>> order
>>> to avoid problems that cannot be solved by changing PATH. Please do not try
>>> to
>>> divert from this general problem.
>>>
>>>
>>>
>> I'm with you there. I don't remember the ARC case # (I think it was the
>> creation of /usr/gnu), but I actually argued the same thing on the
>> conference call. I think the only difference is that When I hung up from
>> the conf. call, I understood that while my argument was heard and
>> understood, it wasn't deemed to be enough to change things, and I knew
>> they decided to go ahead anyway. Ao I wasn't surprised when the gnu
>> binaries appeared in /usr/bin.
>>
>
> Well, then we seem to have very similar ideas.
>
> A big question still remains: what is "GNU software" and should non-gnu
> software go to /usr/gnu?
>
That (If I recall correctly) was one of the questions raised on the
conference call and email thread. I was never clear why that was a good
reason not to do it but it was a variable some didn't appear to like.
Personally I'd only put in the FSF stuff - but that left another
questions, that I think some didn't want hanging out there, to answer:
Where does the other stuff go? How big does a collection have to be to
get it's own /usr/gnu equivalent? is there a /usr/misc that collects all
the things that don't qualify? Should all these collections be collected
in another directory (/usr/some/path/{gnu,schilly,misc,...})? Should the
gnu equivalents of things already in /usr/bin, /usr/ucb, /usr/xpg*, be
left in /usr/gnu since they could be considered 'UNIX types', but things
not traditionally in UNIX (gcc, ghostscript, xemacs, etc.) put in
/usr/some/path/somename?
I don't know the answers to all therse questions. I beleive they are
answerable, but I know Sun had a timetable, and probably didn't want to
hold up that one ARC case to hashing out this bigger problem.
Looking at it now, the answers to those questions probably seemed to
lead right back to something too close to /usr/sfw... I know there are
opinions out there that /usr/sfw was a mistake. I'm not totally clear on
what they didn't like about it technically, but I think I might try to
look it up if I get the chance.
> The important conclusion from the current name clash problem should be:
>
> - Only a small selected number of binaries are allowed to live (also) in
> /usr/gnu. This would include gtar, cc and gcc but it may be that we even
> need to discuss whether "tar", "pax" and similar should be there.
>
I think the /usr/gnu case decided only things that were GNU (FSF I
bleieve) that *conflicted* with things already in /usr/bin were to be
put in /usr/gnu. This means that you might find GNU tar under the name
tar in /usr/gnu, and again under the name gtar in /usr/bin, but you
wouldn't find gtar in /usr/gnu. GCC would be found in /usr/bin I assume
ince I know of no conflict.
> - As long as even in a multi-user environment users cannot customize
> their
> private view to /usr/bin, /usr/bin needs to be treated very carefully.
>
>
The idea was to leave /usr/bin as the default catchall. And allow people
to stick things in front of it in their PATH to bring conflicting thins
from GNU, UCB, XPG etc. to the front for themselves, and let the PATH
'fall through' to pick up everything else by default.
> - Instead of putting everything into /usr/bin, it is better to have a
> longer PATH by default that defines the default behavior of the
> installation (e.g. from /etc/default/login)
>
>
There are hard and fast rules inside of Sun, from experiences with
customers (from what I remember) complaining when the default PATH had
been changed in the past. No one was willing to discuss changing the
default PATH in /etc/default/login.
> - It may be even wise to create something like /usr/sun/bin or
> /usr/sol/bin
> to really allow to customize the userland behavior of OpenSolaris.
>
>
I think that might also be a good idea. If /usr/bin is to be a catchall,
then like UCB, and XPG, I think breaking out the SVR4 variants of the
'basic UNIX' commands (getting everyone to agree on a definition of that
list might be tough) might be useful too. Even if it's only to Put all
'environment flavors' on equal footing. But I think that would involve
touching the default PATH, and that was described as a 'non-starter'.
> - The current state is an intermediate development state that does not
> grant "stability", so any change is still possible as long as Solaris 11
> has not been published.
>
>
We'll see.
> Jörg
>
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
