On 05/11/2007, Gary Gendel <[EMAIL PROTECTED]> wrote: > 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.
Unfortunately, you're always going to have to worry about new additions possibly causing this. The GNU group might release a new tool at any time, and the old tools are slowly being added as ARC cases get approved for them. > 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? That's a problem you're going to be stuck with. gcc belongs in that directory; along with all of the other related tools. Broken scripts are going to have broken behaviour. You could benefit everyone by ensuring patches for this broken behaviour gets sent upstream. As a developer; I deal with this frequently. I've accepted that people are always going to write non-portable software and that I (unfortunately) am going to have to deal with those consequences. Usually I find that scripts that insist on using gcc and ignore the CC environment variable are hard-coded to use gcc-specific compiler flags anyway so more fixes have to be done. Your argument for gcc applies to almost every tool found in that directory; so I don't see this problem going away. > >> 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. Indiana is only a preview at this point so no one is expecting it to be deployed in such a manner anyway. Remember that the consolidations it contains still need to go through ARC, etc. and when it does, you can be certain that these issues will be addressed. Until then, I wouldn't sweat it too much; this is just a prototype and a place for experimentation. The changes have not been integrated into Solaris proper, etc. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "We don't have enough parallel universes to allow all uses of all junction types--in the absence of quantum computing the combinatorics are not in our favor..." --Larry Wall _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
