Hide Forgot
The current version of xerces-c in EPEL5 is 2.7.0-8.el5. However, CentOS Extras provides xerces-c 2.8.0-1.el5. Yum suggests to upgrade to the 2.8 package in CentOS Extras, but this doesn't work because other packages in EPEL like blahtexml 0.8-1.el5 depend on xerces-c 2.7. ---- # yum update xerces-c (...) blahtexml-0.8-1.el5.x86_64 from installed has depsolving problems --> Missing Dependency: libxerces-c.so.27()(64bit) is needed by package blahtexml-0.8-1.el5.x86_64 (installed) Error: Missing Dependency: libxerces-c.so.27()(64bit) is needed by package blahtexml-0.8-1.el5.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest ---- I understand that the extras repository is not base/updates, but it is enabled by default on CentOS and CentOS compatibility is explicitly mentioned in the EPEL homepage, so for compatibility it would be nice if the xerces-c package in EPEL could be updated to version 2.8.
"CentOS compatibility" only refers to the CentOS repositories actually compatible with upstream RHEL. CentOS Extras is NOT compatible with EPEL.
See the warnings about EPEL on: http://wiki.centos.org/AdditionalResources/Repositories "It should also be noted that, while EPEL may not overwrite distro packages, it may have conflicts with the CentOS extras repo which is enabled by default."
(CentOS blames EPEL, but I'd blame CentOS for not caring about EPEL compatibility, instead duplicating the efforts with their CentOS extras repository and providing different versions of the same shared library with the same package name and no compatibility package.)
This issue was reported to Fedora EPEL, not to CentOS. If EPEL doesn't want to fix this, well, there's nothing I can do, but what's the point of running an additional repository that's not compatible with the base repository?
> This issue was reported to Fedora EPEL, not to CentOS. That's your first mistake. It's CentOS extras causing the breakage by shipping a different version of a library EPEL already ships. > If EPEL doesn't want to fix this, well, there's nothing I can do EPEL cannot easily fix this because the new version is API-incompatible with the existing version in EPEL. > but what's the point of running an additional repository that's not compatible > with the base repository? CentOS extras is not a base repository, it's a repository with additional nonstandard stuff which is not in RHEL or other RHEL rebuilds (such as Scientific Linux). Why they enable this by default is beyond me. Either use exclude=xerces-c on extras or disable extras entirely, then yum downgrade xerces-c.
(Actually, yum downgrade should not be needed unless you already upgraded to the new incompatible version.)