[OpenIndiana-discuss] Namespace management and symlinks in /usr

[Reginald Beardsley]

--- On Wed, 10/17/12, Udo Grabowski (IMK) <udo.grabowski at kit.edu> wrote:

> From: Udo Grabowski (IMK) <udo.grabowski at kit.edu>
> Subject: Re: [OpenIndiana-discuss] Namespace management and symlinks in /usr
> To: "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org>
> Date: Wednesday, October 17, 2012, 10:11 AM
> On 17/10/2012 16:50, Reginald
> Beardsley wrote:
> > In chasing the Firefox/Java issue, I happened to look
> at the symlinks in /usr.  I'm rather disturbed by what
> I find.
> > 
> > There are 15715 in my installation of oi_151a.
> > ...
> > Yes, it is painful to force people to fix their
> scripts, but in the end, indulging bad behavior just makes
> the problem worse.
> > Having written scripts that ran cleanly across Ultrix,
> SunOS, AIX, HPUX, Irix and more I know it's not hard to do
> things w/o
> > resorting to polluting the system namespace w/
> bandaids.
> > 
> 
> This is for people running heterogenous systems, like old
> Osol
> combined with new OI, or for people upgrading from Osol to
> OI
> for not having trouble with scripts after upgrade, and
> problems
> with configure setups for software (on solaris you usually
> have
> to patch configure scripts, and it's a pain to redo this on
> every upgrade). So having these symlinks is a good thing,
> and
> when these old systems gradually die away, people will
> adapt
> their scripts, but at least up to the next stable release
> of
> OI these links should be kept. As there's usually not much
> left in
> these legacy directories, they will quickly become a simple
> symlink to the default places.

To paraphrase your response:
"
"These links are good because they keep people from having to fix badly written scripts.

When there are more symlinks people will fix their scripts."

It's been my observation that rather than fix the badly written scripts, they just write more badly written scripts and the problem gets worse rather than better.

The following *really* isn't a lot of work the first time, and it's easy to fix when it does break.  When I was writing scripts that needed to run across 6 distinct flavors of Unix, I had a boilerplate file I placed at the start of the scripts to handle all this stuff.   Typically took about 10-15 minutes to update all the path information for a new platform and that was for a version control and build system I wrote.

if [ -e /usr/sfw/bin/fubar ]
   then
   FUBAR=/usr/sfw/bin/fubar

elif [ -e /usr/bin/fubar ]
   then
   FUBAR=/usr/bin/fubar

else
   echo "Can't find fubar"
   exit

fi


As for ./configure,  setting PATH properly will take care of most of those.  The ones it won't fix generally can't be fixed.

Reg