On 10/17/12 06:58 PM, Reginald Beardsley wrote:
--- On Wed, 10/17/12, Udo Grabowski (IMK) <[email protected]> wrote:
From: Udo Grabowski (IMK) <[email protected]>
Subject: Re: [OpenIndiana-discuss] Namespace management and symlinks in /usr
To: "Discussion list for OpenIndiana" <[email protected]>
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
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
