Bart Smaalders wrote:
> 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: ?
>
Because for me /usr/local/bin(for the sake of conversation) for me is a
soft link to an nfs mountpoint.
[I like to only install and maintain this stuff on one file server, not
locally on every machine.]
I don't think putting an NFS mountpoint before /usr/bin, /usr/ucb, etc.
in a users $PATH is a good idea.
> 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.
>
True. If I don't mind maintaining everything locally on every machine.
> 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
>
>
>
I'm sure that could be shrunk down quite a bit.
/usr/ccs/bin, /usr/sadm/admin/bin, could probably be shrunk merged to
/usr/bin. (I'm not sure what's in the later though.)
/usr/dt/bin and /usr/openwin/bin, I imagine will eventually be nearly
empty with most everything being found in /usr/X11/bin.
That leaves:
/usr/bin, and /usr/X11/bin. Plus /usr/{sfw|gnu|lsb|linux|opt|whatever is
decided on} if desired, and optionally a /usr/{ucb|xpg4|etc.} prefixed
on the beginning to select an alternate environment.
-Kyle
> - Bart
>
>
