Bug 520323
Summary: | qt-devel must Requires: phonon-devel | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Axel Thimm <axel.thimm> |
Component: | qt | Assignee: | Than Ngo <than> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | kevin, ltinkl, rdieter, than |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 4.5.3-7.fc10 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-11-04 12:03:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Axel Thimm
2009-08-30 16:25:30 UTC
This will be fixed when (if?) we switch to using qt's phonon. (currently in rawhide, other releases when qt-4.5.3 lands) Though I'm a little surprised, I thought Libs.private were only used for static linking ? (In reply to comment #1) > Though I'm a little surprised, I thought Libs.private were only used for static > linking ? Looks like the dependency surfaces when building for example mythtv 0.22. The build log in the report doesn't look like a static build. Maybe a pkgconfig bug exporting Libs.private to the external builds? Another thing I'll just do is... since we're purposely not including static libs anyway, strip Libs.private from qt's pkgconfig files so consuming apps won't even try to use them. Fwiw, $ pkg-config QtWebKit --libs -lQtWebKit -lQtDBus -lQtGui -lQtNetwork -lQtXml -lQtCore $ pkg-config QtWebKit --libs --static -L/usr/X11R6/lib -L/lib64 -lQtWebKit -lphonon -lQtDBus -lQtGui -lQtNetwork -lQtXml -lQtCore Implies your build (mythtv) is purposely requesting static linking here. It looks like all mythtv does is using_qtwebkit { QT += webkit DEFINES += USING_QTWEBKIT } (that's all a case independent grep on all *.pro files yields) Ah, likely coming from the qmake-fu in %{_libdir}/QtWebKit.prl Ugh, the circular dependency is a little more madness than I'm willing to partake of, so my only suggestion is to workaround it by adding BR: phonon-devel until 4.5.3 lands. (abusing closed->deferred as that closely matches the plan here) (In reply to comment #6) > so my only suggestion is to workaround it by adding > BR: phonon-devel > until 4.5.3 lands. > > (abusing closed->deferred as that closely matches the plan here) But if it's marked closed->anything the workaround will never be applied, or did you commit the workaround to CVS? As outlined in comment #1, this is fixed in rawhide already (by using phonon from qt directly, not standalone). This is also planned to propogate back to previous releases (F-10, F-11) when 4.5.3 happens. The workaround I mentioned was for apps with problems, like mythtv, to (temporarily) add BR: phonon-devel But isn't adding the workaround to the qt package better (which carries the bug after all) than modifying N clients and later removing the temporary fix (or forgetting it forever there)? It looks like anything using the webkit is affected. (Unless 4.5.3 into F10/F11 is something imminent - I have no idea how the schedule looks like - in that case waiting for the bug to go away is OK) The problem is that the qt -> phonon -> qt dependency is circular. The problem is that the qt -> phonon -> qt dependency is circular. But the dependencies are run-time dependencies of *-devel packages, or not? Does it really matter? Such a circular dependency just means that the packages need to be installed together or not at all. The circular dependency is a fact, you obviously need phonon-devel with qt-devel (when using webkit), and vice versa. Re-opening, confirmed my suspicions regarding the .prl cause (comment #6) And, we've backtracked/waffled a bit on our plan to use qt's phonon, so I'll at least fix the .prl file causing this particular issue. qt-4.5.3-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/qt-4.5.3-4.fc11 qt-4.5.3-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update qt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10447 qt-4.5.3-4.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update qt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10462 qt-4.5.3-7.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. qt-4.5.3-7.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |