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