Am I really that hard to understand?!
When you're in your element, you're crystal clear.
No. You don't understand. It's not the folder that the files are
stored into that I care about. It's the fact that they have pathnames
compiled into their code. For example, "where are my configuration
files?" "Where are my binaries?" etc, etc. The path names to these
things are configured at compile-time using a ./configure (autoconf)
type script, or a similar mechanism.
Golly, jeepers, Scott! Usually this stuff is under /etc and we're not
talking about that at all. I have yet to see a package that looks under
/usr/local for its configuration files (it may look in its own directory or
in a subdir of same, but that's not the same thing). Its binaries are
invariably either expected to be in PATH or under its "home" directory
(usually directed by some environment variable, so it doesn't care where it
is).
OK, smart guy. Since I don't seem to be making myself understood, let's
take a real world example I've mentioned before. Let's say we want to
install AIX zip onto the system, and just for grins we'll put it into
/usr/local/bin (symlinked to /QOpenSys/usr/local/bin) because we don't know
another way. Lo and behold it works great. But now in my qsh session I
have a zip tool... and it's in the path! Cool! But wait, what's this... It
won't execute because it's not in the right environment. And it's true of
unzip and zipinfo and all their friends. You like this? What advantage was
wrought by installing in this way?
The alternative: Use chroot to make /QOpenSys/usr/local/bin appear to be
/usr/local/bin without any symlink. This is a short-term step. Now do the
installation. Now exit the chroot environment so that all is "normal"
again. (Make sure there's no damage to your body after this grueling
experience.) Amazingly, we have a zip utility in PASE that works fine in
PASE. And if we look in (the real) /usr/local/bin we find it blissfully
absent of PASE objects.
That means if you're going to download AIX binaries to run them in PASE,
you need things to be found under /usr/local instead of
/QOpenSys/usr/local.
One example, please? Just one. This is not a condition I have countered.
If it were as simple as modifying the system PATH, I sure as heck
wouldn't have created the symlink!! It's not that simple.
Thanks for clarifying what it isn't.
I don't agree. You are crippling the system for no good reason that I
can fathom.
In what way is this crippling the system? Because I don't want something in
the PATH of a qsh session if it won't execute? Is that your definition of
crippling?
You agreed (I think) that some of these programs won't run under QSH
and yet
you install them under QSH because it's easier (that's the way I read
your
post).
No. I said your chroot idea would make it impossible to interact with
QSH. I didn't say I installed PASE utilities under QSH! I use them
from QSH, and why shouldn't I? Having these environments (QSH & PASE)
work together is a really GOOD thing!
You are quite mistaken. How in the world will using chroot to do an install
prevent that application from later accessing anything it needs, Scott? Am
I that hard to understand? Do you need specific installation instructions?
It is true that you didn't say you installed PASE utilities under QSH; you
seem unwilling to admit it. I said that about your approach. If you put
something into /usr/local/bin directly or by symlink, you have put it into
the PATH of QSH (and therefore into that environment) whether you like to
admit it or not!
I am presenting an alternative that allows you to do it right,
keeping the Hatfields and McCoys on their own properties.
Really? What alternative have you presented, exactly? All I've seen
so far is "I found one piece of software once that wouldn't work with
your symlink idea. Therefore you shouldn't use it even if it does work
brilliantly". That's the way /I/ read /your/ message.
The alternative, once again, Scott, is to chroot before the install. That's
all. I don't know how many ways this needs to be stated in order to be
understood. You obviously are not reading or are not understanding that
alternative. Hopefully my (very short) example above (hint: zip) will help.
If you still don't get it... well I don't know what to say.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"We are told that talent creates its own opportunities. But it sometimes
seems that intense desire creates not only its own opportunities, but its
own talents."
-- Eric Hoffer
midrange.com
