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 <j.p...@tesco.net
> <mailto:j.p...@tesco.net>> 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
