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

Reply via email to