SCIENTIFIC-LINUX-USERS Archives

April 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Tue, 23 Apr 2013 00:17:26 +0900
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
On 04/22/2013 11:54 PM, Yasha Karant wrote:

> We too have found similar issues when we leave SL6x and obtain compiled
> RPMs (binaries) from other repositories, usually requiring the
> enablement of that repository in the list of repositories from which to
> seek the dependency RPMs.
> I am not asking for a strict resolution of this issue from the SL
> providers.

Resolving conflicts with repos not under their control is, um, not under 
their control.

> Rather, is there a way to get a list of conflicts between repositories?
> Is there a way to do an accurate "dry run" so that one can discover
> dynamically (at the time when one is contemplating the installation of a
> RPM) of the conflicts? Is there a way to automatically select the
> precedence of repositories?

As for discovering conflicts without installing, this is another thing 
which, by definition, is not possible. If there were listed dependency 
problems then yum would catch them when it checks the dependencies. But 
since all the dependencies are listed as checking out there is no way to 
know whether they will break or not based on how they are built. 
Utility/lib A from repo A is indeed lib A, but was deliberately not 
built with options X and Y enabled, options providing critical 
functionality required by package B from repo B, etc. You can only know 
this when you actually run package B and watch it die.

As for repo priorities, though, you are in luck -- and this is really 
what you need. There are two (and a half) ways of doing this. You can 
read "man yum.conf" and check out the "cost" option. This can be 
unreliable if network paths to some of your primary repos are down 
during an update. The other (better) way is to use 
yum-plugin-priorities, a yum plugin designed for this.

The other half way which is invaluable in certain circumstances is to 
configure yum to only install specified packages from a certin repo and 
ignore everything else.

-z

Btw, this is a pretty baggage-laden way of starting a thread... couldn't 
you just send a fresh email to the list?

ATOM RSS1 RSS2