Re: Yum packages (again)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux