Timothy Selivanow wrote:
Another example is Fedora's alternatives system (which, for example,
allows multiple versions of Java to coexist) but again that requires
specialized logic.
Question: how many levels of symlinks-pointing-to-symlinks does it take
to get to the right place? And having supplied this number of symlinks,
how can a user choose to execute one version of java while someone else
prefers the other? Or how do you run one application under one version
and another with a different one?
There are several levels, just guessing off the top of my head, some
might go through 5 or more. As far as choosing which one...the system
gets one configured, the one that is /usr/bin/java (you can do a
`/usr/sbin/alternatives --display java` to see what it is currently).
For using all others, you have to explicitly tell it to use a specific
java enviro.
For instance, something that you are familiar with: in tomcat4.conf,
you can set JAVA_HOME="/usr/lib/jvm/java",
Except, of course, that you have no reasonable way to know this location
for the package(s) in question.
The point is, you need to explicitly setup the environment /each time/,
whether at command line or some other setting.
Well, sort of. $HOME conveniently manages to be both unique and correct
for different users at the same time and there are well-known ways to
manage other personalized variables.
Symlinks only provide a
default. Yes, you can do what you have been wanting this entire thread:
install things into a different directory tree so that you can have
independent version running simultaneously. The trick is the
environment needs to be set up each time in order for it to work.
And that's not a difficult trick, given an OS where environment settings
are always inherited from parent processes but you can change them when
needed.
The big problem with doing it with RPM, is that there is no central
authority on who gets to put what where. Having
a /usr/local/foo-repository/package1 and
a /usr/local/bar-repository/package1 doesn't solve any of the problems
that are described. Having customized directory structures only works
on a case-by-case and as-needed basis, as they are not trivial, and
there is really no way for a user (not admin) to be able to make those
kinds of decisions.
If they have different names a user can choose which he wants just like
any other thing he chooses. Or if the user only knows how to click,
different icons can do everything necessary.
If you want a program compiled against different
libraries, and have a user be able to access both, best way it to have
it done in a custom fashion, building the environment using scripts if
need be.
Why? If there is a way that works in the custom case on one machine, it
will work on another machine without duplicating the custom work.
That all said, the best way to get repo mixing is probably just
plain-old co-operation, and a bit of know-how.
Perhaps someone who uses several jpackage packages can comment on how
things are working out in FC6/7 and Centos5 where some small subset of
things that look like jpackage packages have been included in the core
repos? So far I don't see how this is going to work unless the whole
mess is included. To simplify this, I understand how environment
variables work and find them very predictable. I can't predict what two
different repositories are going to contain tomorrow and don't ever
expect to be able to. I'd rather trust my luck to the thing I can control.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
