Shawn Walker wrote: > On 02/11/2007, Gary Gendel <[EMAIL PROTECTED]> wrote: > >> Putting the gnu tools at the front of the default path raises the question >> how are we going to resolve the conflicts between tool name collisions? I >> really don't care that the gnu tools are available, but it also means that >> as Indiana upgrades add more gnu tools, the expected environment changes in >> unpredictable ways. >> >> > > You don't. The PATH is the only way to control how and if naming > collisions happen. The reality is that this has been an issue for a > long time already on Solaris depending on how you setup your path. > > True and not true. Previously, the gnu tools were relegated as second class citizens in OpenSolaris by default. However, some bits (ginstall, gtar, gmake, etc.) were promoted to first class citizenship by virtue of their naming. This is a new paradigm where the gnu tools have been moved to be a first class citizen and the SYSV tools relegated to second class status. Now I can't type gtar vs. tar and existing scripts that expected the SYSV install will get the gnu install.
I don't have a problem in general with your statement or the swap of class status. What I do have a problem with is that this won't be a one-shot deal. Instead, I expect more gnu tools to be added in an ad-hoc manner, leaving this situation in flux for the foreseeable future. Let me make another example to demonstrate why I'm concerned: There are open source packages that: 1) Require gmake. 2) Require ginstall. 3) Use gcc, if it is anywhere on the path, even if you specify CC=cc. I agree that this means that the packages are broken if they do (3) but I've found this to be the case too many times. I have no way to fix it if gcc is put in the gnu bin directory. I would need to build C++ libraries with both with SunStudio and gcc so I deal with the differences in name mangling in each compiler. Is this an acceptable solution, or are we planning to relegate some gnu tools (like gcc) outside of the gnu bin directory so I can remove them when necessary? >> I don't want to figure out which version of what is called when I make a >> call to a utility from a script. Subtle differences can create huge issues. >> For example, the only "ps" extended format I've found in common between gnu >> ps and SYSV is the -L option. I hate to have to go through each utility to >> find the usable subset that is common among the tools so scripts work. That >> becomes a system administrator's nightmare. >> >> > > It has been said that the scripts will have to either be run with an > adjusted PATH or changed to accommodate. > > Yeah, I've already have wrappers around portable scripts that do things like: If ksh exists, use that otherwise if bash exists, use that otherwise use sh and hope it works. The reason for this is because: 1) /bin/sh is really /bin/bash on some systems 2) /bin/bash doesn't exist on some systems 3) bash is a behemoth in the world of shells and most power is in it's interactive behavior which isn't needed 4) ksh's non-interactive job control and error handling works. Now trying to make portable scripts becomes that much harder. Doable, but harder. I've been writing shell scripts since the early 80's. Sometimes people don't understand how small changes will cause big problems. I'd just rather someone say that we're going to make all gnu tools first class citizens and let us deal with the fallout once, not dribble changes over time. It just means that I will never be able to deploy Indiana until this is resolved, or will have to micromanage the installation of packages and have one system relegated system testing before deploying any change to my users. Gary
begin:vcard fn:Gary Gendel n:Gendel;Gary adr:;;;Hillsborough;NJ;08844;USA email;internet:[EMAIL PROTECTED] tel;work:908-369-0334 tel;home:908-369-5496 url:http://www.genashor.com version:2.1 end:vcard
_______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
