ken wrote: > On 01/24/2010 04:59 PM Nicolas Thierry-Mieg wrote: >> ken wrote: >> <snip> >>> Then I found and read >>> http://wiki.centos.org/AdditionalResources/Repositories?action=show&redirect=Repositories. >> >> as stated on that page, mixing 3rd party repos does not always work so >> well. Your problem is an example of what can go wrong. > > Yes, I saw that warning... in the section on epel. There's also a > general 'mea non culpa' on that page about using 3d party repos in > general. For that matter, I'm pretty sure that there's a "we don't > guarantee" clause packaged somewhere in every linux distro. I even got > that line at work from paid-for redhat support in regard to a paid-for > redhat system. If I stopped doing things that "might not work", I'd be > fastened to the couch with cobwebs. I tried several of packages from > epel and they worked-- at least I haven't traced any specific problem > back to epel... well, until now... with your help. Point is, I don't > feel much tech shame for getting a package from epel. I figure that if > it was a terrible repo, it would say so in the centos wiki... or epel > wouldn't be listed there at all. epel is not a bad repo, it's just mixing repos that causes problems. If you install unrelated packages from this and that repo you can be OK, but otherwise (eg if they're related through a dependancy as was the case here), you can run into problems. >> .... >> >> epel is one of the big 3rd party repos, rpmforge is another. >> >> you are installing libdvdread from epel and trying to install >> gstreamer-plugins-ugly from rpmforge. >> Unfortunately the former doesn't have the right lib version for the latter. > > Right, and that's what was bugging me from the start: I had > libdvdread.0.4 installed and gstreamer-plugins-ugly wanted a *lower* > version. Aren't all the capabilities/functions from the 0.3 version in > v.0.4? My hunch was that, yes, they would all be there. This is basic > upward compatibility, a part of what linux has been about for decades. > If I had the time, I'd compare the two libdvdread library files to find > out for sure. The point of it would be to find out why the > gstreamer-plugins-ugly rpm complains about the newer libdvdread version. > To my mind, that simply shouldn't happen... might be an error in the > way it was packaged. if the soname version changed chances are it's not compatible ;-) that's why shared libs are versioned. > >> >> One solution would be to give higher priority to rpmforge over epel. >> Then uninstall [the epel] libdvdread, and yum install >> gstreamer-plugins-ugly should properly pull in the rpmforge libdvdread. > > Yes!! That works... at least to get both of those packages installed at > the same time. However, totem is still broke; i.e., it's still telling > me that I'm missing a plug-in when I try to play a movie (mpeg-1 or wmv). > > > Hmmm. I didn't mention this previously for the sake of simplicity, but > few hours ago I did have both libdvdread.0.4 and gstreamer-plugins-ugly > installed at the same time and was able to play a movie (mpeg-1) in > totem. But "yum update" complained about it, so I figured I should fix > it. :( If anyone from redhat or someone packaging gstreamer should be > reading here, this might be a direction to look into. > > > Thanks again, Nicolas. You did help, but I guess totem needs more than > you and I together can give it. well now that you have configured the rpmforge priority high, you should be able to yum install xine (or mplayer), so that it comes along with all its deps from rpmforge. Like Mark, I've always preferred them both over totem. I know the rpmforge xine and mplayer install and work fine. Although this will only work if you don't have other conflicting versions of packages already installed from eg epel or elsewhere. Otherwise you might have to remove those versions so they get pulled in from rpmforge, like you just did for libdvdread. This can get hairy if you've got tons of various packages coming from different repos.