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

[Udo Grabowski (IMK)]

On 10/17/12 06:58 PM, Reginald Beardsley wrote:
>
>
> --- 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.

When you have a big bunch of users and tell them "Hey, tomorrow
we upgrade, and then you can't work for a while because your
scripts and programs will surely break (esp. those of people
no longer in the institute), so you have to interrupt and
fix your stuff NOW !", you will surely find a job opportunity
the next week for a new system administrator on your institutes
webpage....
What you are proposing is maybe ok for small systems with one
administrator and a few users max., but not for large deployments.
A typical upgrade in our server farm lasts about 3 month or more,
and such unnecessary additional distractions will make such an
upgrade even more unpleasant, as program compatibility is prime
in science to have reproducable results (and nobody working here
does have time for such additional hassles totally unrelated to
what they are paid for), and interruptions in the production
chain are not tolerated at all. We put a lot hard work into the
new system before upgrading to make it 100% compatible.
The adaption of programs to new environments always happens
gradually and evolutionary after the upgrade, with some mild
pressure from the administrator, but not in one go by slapping
into everyones face crying "Wake up, upgrade time !"....
-- 
Dr.Udo Grabowski    Inst.f.Meteorology a.Climate Research IMK-ASF-SAT
www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology            http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026