On Mon, 2008-02-25 at 12:03 +0100, Michael Schwendt wrote: > 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. > Considering these remarks I don't really care - I can fix the problem my end, but if you want to live with the system operating like this then fine. A word to the wise - you attract more flies with honey. If your system ends up being a pain with installing packages that people want to install (and not all repos offer the same packages) then they will simply move away. Consider then who will support the project? I'm used to overcoming difficulties like this, but a simple solution to this problem would appear to be in Yum - not the repo offering similar packages to another. Yum is not reporting properly what is being installed in a fedora system. What you are saying in this is that if anyone uses the same name as another package then everything can go to hell and back - even if the installed files are different (it could even be a different program altogether). This doesn't raise an eyebrow with anybody? I'm not going to add anymore to this one, it appears I'm a lone voice of reason here.
