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