x11-libs/qt-webkit-4.8.2 defaults to USE="-icu" while www-client/chromium-21.0.1180.11 and probably other versions too need libxml2 with icu. This can be solved by echo "x11-libs/qt-webkit icu" >> /etc/portage/package.use but should rather be default. dev-libs/libxml2:2 (dev-libs/libxml2-2.8.0-r1::gentoo, ebuild scheduled for merge) pulled in by dev-libs/libxml2:2[!icu?] required by (x11-libs/qt-webkit-4.8.2::gentoo, ebuild scheduled for merge) (dev-libs/libxml2-2.8.0_rc1::gentoo, installed) pulled in by (no parents that aren't satisfied by other packages in this slot) It might be possible to solve this slot collision by applying all of the following changes: - dev-libs/libxml2-2.8.0-r1 (Change USE: -icu)
Same problem for me. It has broken updates for me since I have both www-client/chromium installed and media-gfx/freecad, which apparently requires x11-libs/qt-webkit.
I don't think there is anything we can do on the chromium side; the use-dep is probably there for a reason.
I don't think we (Qt) want to enable icu by default, especially since the recent mess with it (bug #413541). But if a case can be made for a better user experience, let's hear it!
chromium requires libxml2 with USE=icu (when using system libraries), in fact the original patch to add icu support came from chromium: http://code.google.com/p/chromium/issues/detail?id=29046 And enabling a USE flag by default because of an unrelated package does not look like the way to go
I'm not going to enable USE=icu by default in qt-webkit. We had it enabled some time ago (to satisfy a REQUIRED_USE constraint), but we received many complaints for that. Furthermore, upstream disables text_breaking_with_icu by default in qt-webkit-4.8.x
The problem, as I see it, is not with the defaults. It's that Chromium requires the icu USE flag and qt-webkit requires !icu, which means I can no longer have both installed.
(In reply to comment #6) > The problem, as I see it, is not with the defaults. It's that Chromium > requires the icu USE flag and qt-webkit requires !icu, which means I can no > longer have both installed. You can because qt-webkit does not require !icu but defaults to. You can by adding "x11-libs/qt-webkit icu" to package.use and disable the default here. The whole conflict is based on libxml2 which is required for both. So it seems that a qt-webkit, which has no icu enabled, cannot just work with a icu-enabled libxml2?
(In reply to comment #6) > The problem, as I see it, is not with the defaults. It's that Chromium > requires the icu USE flag and qt-webkit requires !icu, which means I can no > longer have both installed. You can have both installed, but only if qt-webkit has icu enabled. Honestly, a news item would have helped here. I had to read the changelog and track down this bug to figure out why things had changed. I imagine that a more novice user would have been very frustrated by the experience. Sure, things only go sour if you try to use both QT or KDE and Chromium, but is that REALLY all that rare a combination? In general Chrome has 33% market share, and I imagine the figure is higher on Linux, and quite a few of those users are going to be on KDE. Arguably a very popular browser on a very popular desktop environment should "just work," but if we're going to compromise and not have it work by default we should provide some kind of advice to users on how to make it work.
(In reply to comment #8) > (In reply to comment #6) > > The problem, as I see it, is not with the defaults. It's that Chromium > > requires the icu USE flag and qt-webkit requires !icu, which means I can no > > longer have both installed. > > You can have both installed, but only if qt-webkit has icu enabled. > > Honestly, a news item would have helped here. I had to read the changelog > and track down this bug to figure out why things had changed. I imagine > that a more novice user would have been very frustrated by the experience. > > Sure, things only go sour if you try to use both QT or KDE and Chromium, but > is that REALLY all that rare a combination? In general Chrome has 33% > market share, and I imagine the figure is higher on Linux, and quite a few > of those users are going to be on KDE. Arguably a very popular browser on a > very popular desktop environment should "just work," but if we're going to > compromise and not have it work by default we should provide some kind of > advice to users on how to make it work. Its documented in portage itself. Its all about working with portage. http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=2&chap=2 Works for me: > pizarro /etc/portage/portage # grep -r icu * > package.use/common:dev-libs/libxml2 icu > package.use/common:x11-libs/qt-webkit icu
(In reply to comment #8) > Honestly, a news item would have helped here. I had to read the changelog > and track down this bug to figure out why things had changed. I imagine > that a more novice user would have been very frustrated by the experience. It's very simple: just enable the icu useflag for qt-webkit, or enable it globally in make.conf, and you're set! These things happen from time to time on Gentoo, so I don't see what the problem is.
(In reply to comment #10) > (In reply to comment #8) > > Honestly, a news item would have helped here. I had to read the changelog > > and track down this bug to figure out why things had changed. I imagine > > that a more novice user would have been very frustrated by the experience. > > It's very simple: just enable the icu useflag for qt-webkit, or enable it > globally in make.conf, and you're set! These things happen from time to time > on Gentoo, so I don't see what the problem is. I agree it is very simple, and it is very obvious ONCE YOU'VE READ THIS BUG OR THE EBUILDs (the latter assuming you understand the !icu? syntax). However, the output of portage is simply that there is a block, and that qt-webkit cannot be installed with libxml2[icu] and that chromium can't be installed with libxml[-icu]. There is nothing in the output of the emerge command that makes it clear that enabling icu on qt-webkit will resolve this block. It is true that these things happen from time to time - but I don't see that as a good thing. Perhaps the ideal solution is to improve the portage output so that it makes it clear that the simplest solution is to set use=icu for qt-webkit to allow them to co-exist, which isn't obvious at all from the current output.
If people are unable to manage their USE flags, they should switch to another distro. Writing a news item for every change in the default USE flags is overkill IMHO. The only thing that can/should be fixed here is portage's output. The suggestion of setting USE=-icu in libxml2 is plain wrong (I guess because it doesn't check the whole depgraph for performance reasons).
(In reply to comment #12) > The only thing that can/should be fixed here is portage's output. The > suggestion of setting USE=-icu in libxml2 is plain wrong (I guess because it > doesn't check the whole depgraph for performance reasons). After some experimentation I tend to agree. I just posted something on -dev with what I found. More helpful portage output might help users to sort this out.
Gotcha. I guess I didn't quite understand the situation. I had tried specifically disabling icu (assuming it was on by default) but not enabling it. It's working now. Thank you for the help, and I apologize for my confusion.
Other way to not suffer the block is to not enable by default "gstreamer" USE for qt-webkit... but I don't know what would it cause on KDE/QT systems (I have only a few qt apps)
(In reply to comment #15) > Other way to not suffer the block is to not enable by default "gstreamer" > USE for qt-webkit... but I don't know what would it cause on KDE/QT systems > (I have only a few qt apps) It's used for HTML5 audio/video. I would be happier to use another backend for that (I try to avoid the gstreamer mess, and use phonon-vlc for example), but I don't think that is currently possible.
(In reply to comment #16) > (In reply to comment #15) > > Other way to not suffer the block is to not enable by default "gstreamer" > > USE for qt-webkit... but I don't know what would it cause on KDE/QT systems > > (I have only a few qt apps) > > It's used for HTML5 audio/video. I would be happier to use another backend > for that (I try to avoid the gstreamer mess, and use phonon-vlc for > example), but I don't think that is currently possible. And what app is requiring that support? I mean, probably kde people will need that but, for users without KDE (like me) qt-webkit is pulled by, for example, mendeleydesktop and kchmviewer. Have you think about dropping "+gstreamer" from ebuild and put an entry in kde profiles to enable it for that cases?
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > Other way to not suffer the block is to not enable by default "gstreamer" > > > USE for qt-webkit... but I don't know what would it cause on KDE/QT systems > > > (I have only a few qt apps) > > > > It's used for HTML5 audio/video. I would be happier to use another backend > > for that (I try to avoid the gstreamer mess, and use phonon-vlc for > > example), but I don't think that is currently possible. > > And what app is requiring that support? I mean, probably kde people will > need that but, for users without KDE (like me) qt-webkit is pulled by, for > example, mendeleydesktop and kchmviewer. I don't think there is any package that *requires* it, but it is expected functionality for web browsers and similar applications. > Have you think about dropping > "+gstreamer" from ebuild and put an entry in kde profiles to enable it for > that cases? I think we should consider that.
(In reply to comment #18) > (In reply to comment #17) > > Have you think about dropping > > "+gstreamer" from ebuild and put an entry in kde profiles to enable it for > > that cases? > > I think we should consider that. That helps for the case of anybody who doesn't use kde but which still has qt installed. It doesn't help for those who do use kde. That isn't to say that it won't help at all.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > Have you think about dropping > > > "+gstreamer" from ebuild and put an entry in kde profiles to enable it for > > > that cases? > > > > I think we should consider that. > > That helps for the case of anybody who doesn't use kde but which still has > qt installed. It doesn't help for those who do use kde. > > That isn't to say that it won't help at all. Note that gstreamer is enabled by default in desktop/gnome profiles.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > (In reply to comment #17) > > > > Have you think about dropping > > > > "+gstreamer" from ebuild and put an entry in kde profiles to enable it for > > > > that cases? > > > > > > I think we should consider that. > > > > That helps for the case of anybody who doesn't use kde but which still has > > qt installed. It doesn't help for those who do use kde. > > > > That isn't to say that it won't help at all. > > Note that gstreamer is enabled by default in desktop/gnome profiles. Bleh, in that case I am out of ideas :S
Probably a news item telling people how to solve the block could help :/
Please let's continue discussing this issue and possible solutions / improvements on the relevant gentoo-dev mailinglist thread. Bugzilla is not the best venue for this discussion.
*** Bug 428308 has been marked as a duplicate of this bug. ***
