From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: When I run the up2date to update my system, I always get a Warning = "There was a package dependency problem. The message was: Unresolvable chain of dependancies: XFree86-xf86cfg-4.1.0.25 requires XFree86 = 4.1.0. Please modify your package selections and try again OK". Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.up2date 2. 3. Additional info:
Please provide us with: rpm -q --whatprovides redhat-release rpm -q XFree86
[root@jike win2000]# rpm -q --whatprovides redhat-release redhat-release-8.0-8 [root@jike win2000]# rpm -q XFree86 XFree86-4.2.0-72
I upgraded the system from RHL7.X to RHL8.0 .
OK. One more thing. grep ID /etc/sysconfig/rhn/systemid Also, please look in the same file /etc/sysconfig/rhn/systemid for a line: <name>os_release</name> and send me the *next* line after that. It *should* read something like: <value><string>8.0</string></value> (but it may be 7.3 instead of 8.0) My suspicion is that your system is subscribed to the 7.3 channel, and up2date is trying to solve dependencies in the wrong package universe.
I am sure i registered the system under the RHL8.0 channel. The "XFree86-xf86cfg" is included in the RHL7.X and it contains 2 files,there two files is incuded in the XFree86 package in RHL8.0 now. so after i uninstalled the XFree86-xf86cfg package, the up2date agent work fine. What i confused is why the RHN update the XFree86-xf86cfg package which belong the RHL7.x. I think it maybe is a bug.
I just found out myself from a co-worker yesterday. Here's what's going on: 7.3 ships XFree86-xf86config. The system upgrade to 8.0 didn't uninstall it, although it should have to. Then up2date comes along and pulls up a newer XFree86, but none of the newer packages obsolete XFree86-xf86config. And since the latter requires the older version of XFree86, you've got an unresolvable chain of dependencies. It's not an up2date bug, it's a packaging bug. Workaround: remove XFree86-xf86config manually.
Reassigning bug to XFree86
> 7.3 ships XFree86-xf86config. No such thing. It is "XFree86-xf86cfg", and it is obsolete in 8.0 and later. It's not really a packaging bug either, however it can be solved by adding an Obsoletes: line to the packaging. The problem is, that you can't use an old xf86cfg with a new XFree86 - that wont work. When you do an upgrade from RHL 7.x to 8.x xf86cfg is no longer supplied, however there isn't a tool which comes with XFree86 which obsoletes xf86cfg, so making it obsolete it just to force upgrades to work is not technically correct really. That said, there probably isn't a lot of harm done by adding a bogus Obsoletes line to the spec file for the future either, so I probably will. That itself isn't worthy of an erratum update however. The official solution for the time being is to manually uninstall XFree86-xf86cfg from the previous OS release which is causing the conflict. That is a good enough workaround for the time being. Once I've made the changes internally to have the Obsoletes line present, I'll update this report and close it. Any future erratum for RHL 8.0 or later will contain it. Thanks.