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

On 22/04/13 13:40, W K Daniel PUN wrote:

 >
 > On 22 April 2013 17:45, John Pilkington <[log in to unmask]
 > <mailto:[log in to unmask]>> wrote:
 >
 >     On 22/04/13 06:47, W K Daniel PUN wrote:
 >
 >         Hi John, & other,
 >
 >         Thank you very much for your reply.
 >
 >         I did try to use atrpms.  After installing vlc, the system keep
 >         asking
 >         me to update a few libs and when I did it and got following
 >         errors.  The
 >         vlc is working fine with my system at the moment.  I don't 
want to
 >         remove the repos epel and rpmforge from my system.  Do I really
 >         need to
 >         get these updates done?  If don't, how can these update 
messages be
 >         stopped coming?  Or, should --skip-broken be used to work 
around as
 >         suggested?
 >
 >         Thanks,
 >         -Daniel.
 >
 >
 >     You now have a mixed set of packages; I warned you about that.  I
 >     don't think you need to remove the other repos, but you ought to try
 >     disabling them during the installation process.  Todd's script looks
 >     as if it will do that - although you might now need to reinstall
 >     rather than upgrade - but other conflicts may emerge.  I shall
 >     probably be working with variants of that script to reconfigure my
 >     Fedora box, but my experience of mixing these repos is limited.
 >
 >     John P
 >
 > > Thanks John.  I didn't realise that I have already got a mixed set of
 > packages. What I tried to do now is that I remove the vlc package and
 > then reinstall it with
 >
 > sudo yum --disablerepo=* --enablerepo=atrpms install vlc
 >
 > The installation is okay, but the Security update message still come.
 >
 > Extensible Binary Meta Language library
 > libebml-1.2.1-1.el6 (x86_64)
 >
 > Open audio/video container format library
 > libmatroska-1.2.0-1.el6 (x86_64)
 >
 > Modplug mod music file format library
 > libmodplug-1:0.8.8.3-2.el6 (x86_64)
 >
 > Universal Plug and Play (UPnP) SDK
 > libupnp-1.6.18-2.el6 (x86_64)
 >
 >
 > When click on update, I got
 >
 >
 > No packages to update
 >
 > None of the slected packages could be updated.
 >
 > More details
 > vlc-2.0.5-6.el6.x86_64 requires libthreadutil.so.2()(64bit)
 > vlc-2.0.5-6.el6.x86_64 requires libupnp.so.3()(64bit)
 > vlc-2.0.5-6.el6.x86_64 requires libebml.so.2()(64bit)
 > vlc-2.0.5-6.el6.x86_64 requires libmodplug.so.0()(64bit)
 > vlc-2.0.5-6.el6.x86_64 requires libmatroska.so.2()(64bit) : Success -
 > empty transaction
 >
 > How can these 4 updates be stopped?
 >
 > Thanks,
 > -Daniel.
 >


Your last post came direct to me and didn't go to the list.  I still 
haven't found the best way to reply on this list, but please check 
before hitting send.

Note:  I need to heed my own advice here.  Resending to list.

And I suspect that this list, like most others that I use, prefers 
'bottom posting', so I've changed that.

I have just spent the morning moving my Fedora 17 box from an ATrpms 
base to rpmfusion; it still has unresolved problems. I recently did the 
same with my SL6 laptop.  You have chosen to go the other way, so I 
can't easily compare what we see.

Your 'vlc requires' messages may be looking for packages from 
ATrpms-testing, which your command line above won't have enabled - you 
omitted a *.   The name doesn't mean what it says; it just marks 
packages that may change RHEL functionality. The others may be from 
rpmfusion and you may be able to remove them by rpm -e if you don't need 
them elsewhere.  I don't think I can offer any more help.  Good luck.

John P