On 04/22/2013 08:17 AM, zxq9 wrote:
> 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?

The "baggage" makes it very clear as to how much effort and 
correspondence are expended upon this issue -- a theoretical discussion 
in a vacuum by-passes the significant reality of this problem.

A far better solution would be proper overloaded polymorphism (of which 
a very limited instance is provided through lib and lib64).  In 
principle can be done through a specification of the exact execution and 
search path for any program (in which such a path includes both the 
regular path variable in a shell and the loader library path), but this 
mechanism is not widely implemented with the binary RPMs as provided. 
However, such a discussion is a matter of engineering and design, not 
strictly technology; whereas it has been made abundantly clear that the 
SL list is restricted to technology.  Hence my queries as to technology 
without addressing the fundamental design flaw.

Yasha Karant