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?
