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
