Hide Forgot
Description of problem: subversion has a build conflict with kdelib3. When kdelibs3 is installed on a machine a build is not done ok How reproducible: 100% when kdelib3 is installed Steps to Reproduce: 1. install kdelib3 2. rebuild subversion Actual results: if kdelibs3 is installed and kdelibs3-devel not the rebuild fails: g++: /usr/lib/libkdeui.so: No such file or directory g++: /usr/lib/libkdecore.so: No such file or directory g++: /usr/lib/libDCOP.so: No such file or directory g++: /usr/lib/libkdefx.so: No such file or directory if kdelibs3 is installed and kdelibs3-devel is installed too rebuild fails in config script. Expected results: rebuild works ok or inform about a build conflict in any way
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
The bug is in the kdelibs3 package. It comes from the fact that subversion has a BuildRequires on "kdelibs-devel >= 4.0.0", and that kdelibs3-devel Provides: kdelibs-devel 6:3.5.... This was fixed in Fedora some time ago by Rex Dieter: http://pkgs.fedoraproject.org/gitweb/?p=kdelibs3.git;a=commit;h=fcb3f122712fc9f1bc95b530875cad6689c1024a I'm attaching a patch rebased on the RHEL6 srpm. Once a kdelibs3 package has been rebuilt with it, then subversion builds fine.
Created attachment 498432 [details] Rebase Fedora changeset fcb3f122712fc9f1bc95b530875cad6689c1024a This patch, applied to kdelibs3, fixes the build issue in subversion. Note: I didn't change the component for this bug to kdelibs3, I assumed you might have your own processes inside Red Hat and it might not be welcome for random community members to make this kin of changes to tickets.
*** Bug 711434 has been marked as a duplicate of this bug. ***
*** Bug 817794 has been marked as a duplicate of this bug. ***
than this should have to fix for rhel-6/3 final!
The fix in the patch is completely wrong while it actually fixes the issue. This bug should be moved to subversion which has the real problem. This change in subversion.spec does really fix the issue correctly. -BuildRequires: gnome-keyring-devel, dbus-devel, kdelibs-devel >= 4.0.0 +BuildRequires: gnome-keyring-devel, dbus-devel, kdelibs-devel >= 6:4.0.0 When epoch is used in kdelibs it MUST be used in requirements with version... I'd suggest reverting the wrong fix and fixing this in the correct place - subversion.
(In reply to comment #24) > The fix in the patch is completely wrong while it actually fixes the issue. > i don't think the patch is wrong, the patch just drops the old, useless Obsoletes/Provides which can cause such conflicts. > This bug should be moved to subversion which has the real problem. > > This change in subversion.spec does really fix the issue correctly. > > -BuildRequires: gnome-keyring-devel, dbus-devel, kdelibs-devel >= 4.0.0 > +BuildRequires: gnome-keyring-devel, dbus-devel, kdelibs-devel >= 6:4.0.0 > > When epoch is used in kdelibs it MUST be used in requirements with version... > it's correct that the real prblem is in subversion, it must use epoche in the requirement in this case.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-1244.html