On Tue, Jul 10, 2012 at 3:25 AM, Ben de Groot <yng...@gentoo.org> wrote: > On 10 July 2012 11:03, Rich Freeman <ri...@gentoo.org> wrote: > > You keep saying that, but do you have any actual data to back up > that claim? There is no doubt that Chromium is a mainstream and > popular package, but I doubt if it is quite *that* popular as you > make it seem.
See http://en.wikipedia.org/wiki/Usage_share_of_web_browsers . Seems like most of those collecting data estimate Chrome use at 33% market share. Of course, that is across all OSes, and IE has another 33%. I doubt that 33% of Gentoo users are using IE. Until we have statistics collection with a substantial number of participants we'll never really know for sure. > To make a better informed decision, it would be really helpful > to have some numbers of users who have both qt-webkit and > chromium, and those who have qt-webkit but not chromium. Certainly agree with that, but it will be ages before we ever have those kinds of stats. It doesn't appear that we have any working stats collections at the moment (though it seems like an annual GSoC project). > > We all want to improve the user experience. I'm just not convinced > that enabling icu by default, and letting the users deal with the > fallout, is the best way of doing that. Well, I'll agree that finding some way to make it more clear to the user what the compromise is would be better. The problem is that we just don't have any mechanism to do this right now. We could send out news, but that wouldn't make things clearer to new users. We could put it in the handbook, but do we really want these kinds of details there? It seems like portage improvements are the only long-term solutions. Two are necessary in this case (and one likely involves PMS as well): 1. Detection of complementary use deps like these and showing the user the minimum number of changes needed to resolve them all, perhaps with a few alternatives. These could include unselecting packages, or changing their flags/keywords. 2. The ability to trigger package rebuilds when another package changes in certain ways, despite there being no clear link breakage. I believe this was the topic of a lengthy thread and my intent is not to restart it here. There are two weaker substitutes for #1: a. Improve the blocker warning for the !use? case (or its long form), to indicate both ways to resolve the block. I would think that would be a fairly easy change. It won't give the complete solution, but the error messages would contain more of the info to work things out. b. Some kind of hinting system for users might be an option instead. Maybe define some way to include instructions in an ebuild when a particular block is an issue, conditional upon other packages. So, if a user goes to emerge either package and the other is installed/selected, then both packages could display the text "If you want to install both chromium and qt-webkit you need to set USE=icu for qt-webkit and libxml2, and stick a note on your monitor to manually re-install qt anytime icu changes until we fix this mess." I would encourage us to continue to coordinate icu and qt upgrades and continue to send out notices to users every time they need to rebuild qt-core (not that we sent out a notice the first time), until some portage mechanism for doing this exists. The bug isn't really fixed - it just affects fewer people. I'm not sure if we can somehow force qt to link to icu even though it isn't needed just so that revdep-rebuild can detect the breakage (I have no idea what happens when you try to dynamically load an already-linked library). Users who run Gentoo don't mind the odd intervention to keep things moving. However, the problem is that sometimes things break and it is not at all obvious how to resolve them. When error messages occur in some other piece of software it is not clear what needs to be rebuilt, especially when the package isn't linked in. It really isn't ideal to have to hunt in forums or bugzilla to figure out what is going on. Rich
