[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)

[Timothy Selivanow]

On Wed, 2007-08-01 at 16:02 -0500, Les Mikesell wrote:
> Kenneth Porter wrote:
> > --On Wednesday, August 01, 2007 5:04 PM +0200 Dag Wieers 
> > <dag at wieers.com> wrote:
> > 
> >> For the kernel there is a lot of specialized logic to
> >> make it work.
> > 
> > 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", and while you are installing
OpenNMS, you do a `$OPENNMS_HOME/bin/runjava -s` which grabs JAVA_HOME
from env, or `$OPENNMS_HOME/bin/runjava -S <path to JRE>` to set it
explicitly and stores it in $OPENNMS_HOME/etc/java.conf.

The point is, you need to explicitly setup the environment /each time/,
whether at command line or some other setting.  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.

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 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.

That all said, the best way to get repo mixing is probably just
plain-old co-operation, and a bit of know-how.


-- 
Timothy Selivanow <timothys at easystreet.com>
Linux System Administrator
EasyStreet Online Services, Inc.  http://www.easystreet.com