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

Les Mikesell lesmikesell at gmail.com
Wed Aug 1 23:23:30 UTC 2007


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 at gmail.com



More information about the CentOS mailing list