On Mon, 25 Feb 2008 13:36:30 +1000, Da Rock wrote: > Ok, I know a little of this has been covered before, but I have some new > info after some exhaustive debugging. Exhaustive debugging without any proof? Would you please, at least, post a few lines of command-line output to show what you've found out? A lot of what you write is vague and inconsistent. > After the feedback regarding the repo conflicts, I decided to resolve > this once and for all. I uninstalled all mplayer, x264 and xine > packages, and reinstalled only the livna versions. How? With what program? Show "yum repolist" before doing so. > This produced mixed results. Firstly, Yum reported the packages > installed. When you go back and check what is installed (version, etc) > it stated that the freshrpms versions were installed- but only some. Show it. If your freshrpms.repo is disabled and no packages from that repo are installed, yum still shows packages as coming from freshrpms? That would be very weird, because the origin of the packages is determined from looking at the packages *and* the repo metadata. > So I uninstalled it all again. This time I went to the livna site and > downloaded and installed them manually. Now it came up and said > installed, but some codecs weren't installing due to a missing > libx264.so.56. Show it. Most often, when users refer to some vague problems like that, another package in the transaction set takes away libx264.so.56 and offers a different version. > This seemed very confusing to me, so I physically checked the contents > of the rpm. The livna package did contain the library file > libx264.so.56- so why didn't the livna package repo recognise its own > files? It does. Demonstrate how it doesn't. > I also checked the freshrpms version, and this contained libx264.so.58. > Technically then, Yum shouldn't be declaring that libx264.so.56 is > contained in the freshrpms file, Does it? I have strong doubts it does. Once more, prove a bit of what you think you see. > and the 2 versions shouldn't conflict, > should they? If they use the same package namespace, they can update eachother based on which pkg has the higher version. For two packages to coexist, they need to use a different name (unless it's the kernel, which has special support for that in the packaging tools). > So I put it to all- what the hell is going on here? Neither repo appears > to be able to declare what the packages ACTUALLY provide, and Yum is > getting very confused. So who's fault is it? Where does the > responsibility lie? With all due respect, first impression upon reading this is PEBKAC.
