Kyle McDonald wrote:
> John Plocher wrote:
>> Kyle McDonald wrote:
>>> I don't understand the suggestion to 'avoid the conflicts'... How can 
>>> I avoid having the Solaris Perl or GDB or whatever tool not conflict 
>>> with the one I'm installing for my users?
>>
>> It sounds like you really want to be able to choose to NOT install some
>> set of Sun provided OSS packages, because you wish to provide them for
>> yourself, and you are willing/able to cause your user(s) to modify their
>> PATH to include the install location for your new programs.
>>
> Yes. Actualy whether they're installed or not. I just need to be able to 
> promote mine over the default.
>> The problem you have identified is the creeping dependencies
>> that get stuck on the Sun provided packages - you can't "not install"
>> Sun's Perl and install your own because something else in Solaris
>> depends on the "Sun Perl".
> Yes.
>>
>> If you *were* able to do the above (as an admin), would you still have
>> the same issues with this proposal?
>>
> No, If that were true,  I could live with this proposal. I would at 
> least have the ability to do what I want.
> 
> In my situation, since I provide pretty much all the things that I would 
> choose not to install, then no, choosing to not install them is a 
> perfectly fine solution for me. I can still offer my users the ability 
> to configure which of the flavors, or even versions,  they prefer 
> through their PATH... I'm in control.
> 
> I can image though that there will be people setting up systems who 
> might not be in a position to replace all the things they might choose 
> to not install. They're left with an all or nothing solution. They dont' 
> have the option to install the tools, and then set things up differently 
> for different users.
> 
> Thanks!
> 
> -Kyle
> 
>>   -John
> 
> 
> 

So perhaps I don't get something.... why don't you set
your user's path to /usr/local/bin:/usr/bin: ?

You can place your favorite versions of these commands in
/usr/local/bin and be done w/ it, and the system will
still find the versions of things it needs in /usr/bin.

For users who don't wish to customize things, they just
work.

Telling people the default environment can be found
in /usr/bin is more compelling than saying it is in
 
/usr/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/dt/bin:/usr/openwin/bin:/usr/X11/bin:/usr/sadm/admin/bin

- Bart


-- 
Bart Smaalders                  Solaris Kernel Performance
barts at cyber.eng.sun.com              http://blogs.sun.com/barts

Reply via email to