Stephen Harris wrote:
On Wed, Aug 01, 2007 at 04:02:08PM -0500, Les Mikesell wrote:
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?
The question you have asked is a _complicated_ one. Many businesses
have come up with home grown solutions to this problem (in my place it's
called DAM; Dynamic Application Management; default values are determined
by individual/group/server/NIS). It works on Solaris, HPUX, AIX and Linux.
However, it's _definitely_ beyond the scope of an OS package management
system such as yum and rpm.
I could have sworn that when I had yum working right with the jpackage
repos I was able to:
yum install tomcat4
yum install tomcat5
yum install tomcat55
and then run whichever I wanted with the appropriate
service tomcatx start
and if I had modified the config files to listen on different ports I
probably could have started them all at once. Didn't seem that
complicated when the packagers understand the concept. But now I don't
see jpackage repos for centos5 so I don't know how it will mesh with
parts packaged in the base repos with a one size fits all mentality.
Anyone who wants to run more than one version of a specific piece of
software is a "power user" (whether they recognise it or not)
More likely they are just trying to cope with components from different
places that each require specific versions of other things to work at
all. A real power user would modify it all to work with the latest of
everything...
and the
standard pre-built RPMs found in the repositories are _not_ designed
for them.
And that's the problem. I suppose the current solution is to treat it
like Windows DLL-Hell and only run one program per machine - or emulate
that solution with virtual machines whose only purpose is to let you
have some different versioned library that is packaged in a way it can't
coexist with anything else. This just seems unfortunate for an OS
designed long ago to deal with multiple version concepts at all the
necessary levels.
Such a user should build their own versions or use a repository
designed for multi-versioning.
Jpackage seems to be the only one.
You have to recognise the limited problem that the repositories were meant
to solve. They're not meant to be the ultimate answer to everyone's problems;
they're meant to be a simple collection of software then typical end user
can make use of. repotags would help avoid conflicts between repositories.
They are _not_ meant to solve the multi-versioning issue.
They don't prevent it if the packagers understand it. We really
shouldn't need a thousand different linux distributions each with their
own dozen versions and hundreds of updates to sort through to find the
combination you need this week.
Kludges such as "alternatives" is a true kludge requiring the rpm packages to
support it (ie a build time issue) and is not a solution to handling multiple
repos nor multiple versions as a generic solution.
At least we agree on something.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
