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

Thu Aug 2 03:34:17 UTC 2007
Les Mikesell <lesmikesell at gmail.com>

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