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

Wed Aug 1 23:40:03 UTC 2007

On Wed, 2007-08-01 at 18:23 -0500, Les Mikesell wrote:
> 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.

Yes.  That's env magic.

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

MacOS X is known for an ability similar to that.  It's called static
building.  Otherwise, GNU/Linux does exactly that, inherits the env from
parent unless over ridden.  You can do that by making wrapper-scripts.

> > 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 strip the rant away, that's pretty much what I was trying to get
at if you include the below paragraph.

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

There is a way.  Make a custom RPM, or even an advanced script (ala
gentoo ebuild system).  That isn't the problem, it's the name space.
There is no guarantee that what ever you choose it going to be unique
and therefore not over-written by someone else.  How do you think Red
Hat does the dual arch libs in x86_64?  That was dictated though, and
everyone follows it.

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

So far, the reason why it's working is that Red Hat employees and
volunteers also do packages and bug-fixes for JPackage, and it doesn't
work all the time (I also subscribe to JPackage lists).  Excerpt below:

--snip--
On Tue, 2007-07-31 at 08:36 -0700, David Fischer (DHL US) wrote:
> Is there a FAQ on what packages from the fedora side and jpackage side
> can be used together?
> 
> I know I have asked this in the past but it is getting really hard to
do
> a JPackage only fedora when all the version numbers are screwed up.
Can
> you use JPackage and Fedora packages together with out any problems??
or
> do I have to stay in this hell???

This is a little Fedora centric so not 100% sure if this is the ideal
location to ask this, anyway, there is a packaging policy in place:
http://fedoraproject.org/wiki/Packaging/JPackagePolicy
that is being adhered to at least since F-7 meant exactly to avoid this
problem. If you find that fedora packages are violating this policy then
please open bugs against them.

Thanks,
Vivek
--snip--

If you read the packaging policy, it says that it is the *only* case
where they are allowing repotags.  That doesn't even solve the collision
problem, and can even obscure it in some cases.

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