On Tue, 26 Feb 2008 00:22:40 +1000, Da Rock wrote: > > 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 Then why do you keep complaining about things without posting the steps on how to reproduce your problems? I've explained several times before what some conflicts between livna and freshrpms look like, and now you claim that livna without freshrpms has different problems? > - I can fix the problem my > end, Apparently not. > but if you want to live with the system operating like this then > fine. Your problem is not understood yet. Details are missing. > 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? Then do support the project and be cooperative. Post the missing details, and let people look into it. I've been analysing broken dependencies and conflict for a long time, even with the help of some tools. In your case, more information is needed. It cannot be so difficult to post yum output. > Yum is not reporting properly what is being > installed in a fedora system. Show it. Prove it. > 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? ?? It is the definition of "updates". foo-2.4-1 updates foo-2.3-1, because it is just a newer version-release of package "foo". Do you want to complicate it by asking for package foo-2.4-1 to coexist with foo-2.3-1 by default and make it painful for packagers to mark package releases as updates manually? Such as foo-2.4-7 updates foo-2.4-6 but not foo-2.3-1 or foo-1.0-45? foo-3.0-1 updates all older foo releases? If you want an old foo, e.g. foo-1.0-1, to coexist with the newer versions, give it a separate package namespace: foo1-1.0-1 > I'm not going to add anymore to this one, it appears I'm a lone voice of > reason here. No, you only are one of the very few who don't have a solution for mixing of incompatible packages from incompatible sources.
