Bug 100757 - Unresolvable chain of package dependencies for XFree86-xf86cfg
Unresolvable chain of package dependencies for XFree86-xf86cfg
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-24 20:45 EDT by Glen A. Foster
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-29 10:52:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Glen A. Foster 2003-07-24 20:45:39 EDT
INTRO: I can't tell if this is an 8.0 general distribution problem, an issue
with XFree86, or something strange from RHN.  I chose 8.0's distro -- please
forward where/as appropriate.

Description of problem: I have an 8.0 system that was upgraded after ~16 months
of running Red Hat Linux 7.2 and keeping it current with packages from RHN. 
After the upgrade, I applied semi-obvious package installs from the 8.0 set of
"uninstalled at time of upgrade" RPMs.  Aside from the RPM database being
somewhat fragile (need to rebuild it every 2 weeks or so), things are mostly OK.

Today's pull of packages from RHN result in an unresolvable chain of
dependencies, and on the surface, the error message doesn't make sense.
It says:

+=========================== Warning ========================+
| There was a package dependency problem.  The message was:  |
|                                                            |
| Unresolvable chain of dependencies:                        |
| XFree86-xf86cfg                  requires XFree86 = 4.1.0  |
|                                                            |
| Please modify your package selections and try again.       |
+============================================================+

Version-Release number of selected component (if applicable):
# rpm -qa | grep XFree86 | sort
XFree86-100dpi-fonts-4.2.0-72
XFree86-4.2.0-72
XFree86-75dpi-fonts-4.2.0-72
XFree86-base-fonts-4.2.0-72
XFree86-cyrillic-fonts-4.2.0-72
XFree86-devel-4.2.0-72
XFree86-doc-4.2.0-72
XFree86-font-utils-4.2.0-72
XFree86-ISO8859-15-100dpi-fonts-4.2.0-72
XFree86-ISO8859-15-75dpi-fonts-4.2.0-72
XFree86-ISO8859-2-100dpi-fonts-4.2.0-72
XFree86-ISO8859-2-75dpi-fonts-4.2.0-72
XFree86-ISO8859-7-100dpi-fonts-1.0-10
XFree86-ISO8859-7-1.0-10
XFree86-ISO8859-7-75dpi-fonts-1.0-10
XFree86-ISO8859-7-Type1-fonts-1.0-10
XFree86-ISO8859-9-100dpi-fonts-4.2.0-72
XFree86-ISO8859-9-75dpi-fonts-4.2.0-72
XFree86-libs-4.2.0-72
XFree86-Mesa-libGL-4.2.0-72
XFree86-Mesa-libGLU-4.2.0-72
XFree86-tools-4.2.0-72
XFree86-truetype-fonts-4.2.0-72
XFree86-twm-4.2.0-72
XFree86-xauth-4.2.0-72
XFree86-xdm-4.2.0-72
XFree86-xf86cfg-4.1.0-25
XFree86-xfs-4.2.0-72
XFree86-Xnest-4.2.0-72
XFree86-xtrap-clients-4.2.0-72
XFree86-Xvfb-4.2.0-72

... the XFree86 in the 8.0 tree is 4.2.0 -- but RHN wants to put the xf86cfg rpm
(not currently on my system) in with rev 4.1.0, which wants an _older_ XFree86.

How reproducible: on my system, very much so.  In a lab, pretty hard.
Comment 1 Glen A. Foster 2003-07-24 20:57:54 EDT
Eeeek! [wrote it down then found it's _wrong_!]

I *just* saw the XFree86-xf86cfg rpm in this list this time.  So I don't know
exactly where I got it, I'm reasonably sure it was RHN, though.
Comment 2 Mike A. Harris 2003-08-01 04:52:08 EDT
The problem is that XFree86-xf86cfg shipped last in RHL 7.3, so when your
system was upgraded from 7.3 to 8.0, the xf86cfg package was not replaced since
it doesn't exist anymore.  Anaconda ignores that it seems and just upgrades
the system anyway.  Since there is no "Obsoletes: XFree86-xf86cfg" anywhere,
it stays installed and it's dependancies can't be met.  The workaround is to
uninstall XFree86-xf86cfg by hand first, then do the upgrade and it should
work ok.  A future update will most likely add an Obsoletes line to kill
off the package automatically.

Comment 3 Glen A. Foster 2003-08-06 21:48:24 EDT
As expected, removing XFree86-xf86cfg fixed the entire problem.
Comment 4 Glen A. Foster 2003-12-29 10:52:44 EST
Given the support life of 7.x, 8.0, and 9 all expire in 2 days, I'm
assuming this defect will never be fixed/resolved.  --> WONTFIX

Note You need to log in before you can comment on or make changes to this bug.