Yasha Karant <[log in to unmask]> writes:

> I have appended to what is hopefully a new topic (lest I dare modify an existing
> topic and thus contaminate proper list thread indexing) the reason for this post
> -- that is hence a top post (new topic).
>
> 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.
>
> 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?
>
> To be clear, here is my meaning of "precedence".  Each repository can be
> regarded as a set (possibly ordered), with overlaps by package content
> functionality although not necessarily identical revision level of said
> functionalities; e.g., library x.rev(n) versus x.rev(m), m .ne. n. One might
> want a precedence resolution rule.  To be concrete, suppose there are three
> repositories, SL 6x, A, and B.  The rule might be:  use RPMs from SL 6x; if the
> functionality exists in A and B but not SL 6x, use A and replace all SL6x
> dependencies with A; otherwise, use whichever RPMs from SL6x, A, or B, that
> support the maximum number of other requested packages and, in the event of a
> multimodal distribution (ties in the integer maxima),  pick SL6x first, next A,
> and lastly B (thus, in the event of such ties, B would never be chosen).   The
> above would be deterministic.  If the resulting system does not in fact support
> full functionality (use of B "breaks" more important functionalities supplied
> by, say, SL6x), modify the rules, automatically remove the offending RPMs from
> the system that were provided by, say, B, and re-update.
>
> If using the order of precedence methodology above seems too automatic for some,
> then again -- a means to determine dependency conflicts and do a manual
> evaluation before committing.
>
> Yasha Karant

You might like to have a look at the priorities plugin for yum, which is
available as yum-plugin-priorities from the EPEL repo.

Cheers,

Loris

-- 
no sig is good sig