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?
Some people could argue that everything that uses the GPL could go into
/usr/gnu, others could argue that only software published by the FSF has this
right. If you limit the software to software from the FSF, you are sure that
there are no name clashes in /usr/gnu/ if you allos any GPLd software to live
there, even /usr/gnu could have a potential name clash risk.
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.
- 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.
- 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)
- 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.
- 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.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
