FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-10-2012, 02:22 AM
Brian Dolbec
 
Default Portage Output / End User Experience

On Mon, 2012-07-09 at 10:56 -0400, Rich Freeman wrote:
> On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge <peter@stuge.se> wrote:
> > Rich Freeman wrote:

> I don't have a copy of the message but when I got the update to
> qt-webkit the message was fairly cryptic when it added the !icu?
> dependency on libxml2. If anything I think it was less clear.
>
> Rich
>

There have already been users on the forums with that very confusion of
what to do with the cryptic "[!icu?]". And there are currently many
forum threads involving the icu use flag, qt-webkit,...
--
Brian Dolbec <dolsen@gentoo.org>
 
Old 07-10-2012, 03:03 AM
Rich Freeman
 
Default Portage Output / End User Experience

On Mon, Jul 9, 2012 at 10:22 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
> There have already been users on the forums with that very confusion of
> what to do with the cryptic "[!icu?]". And there are currently many
> forum threads involving the icu use flag, qt-webkit,...

Yup, this issue hit anybody who has qt-webkit and chromium installed.

I wouldn't be surprised if that is half of the entire userbase.

We ran into another confusing icu-related issue with qt-core a few
weeks ago (bug 413541). I can understand that the qt maintainers want
to get away from enabling icu for this reason, but chromium is a VERY
popular package so it is really only disabled in the sense that it
annoys a bazillion people who have to un-disable it and then still run
into the problems.

Better portage logic might help here, but I think we need to consider
whether a non-optimal decision from a single package perspective is
going to lead to a better overall experience for our userbase. Zac
suggested adding icu to the profile, which would work, though really
just adding it as the default for these two packages would really
address the issue until portage can catch up.

Those who REALLY don't want icu support in qt-webkit can always
disable it manually now that the flag is there. If there is a fear
that this default will lead to more bugs, those bugs will happen
anyway, since anybody running chromium has to enable that flag.

Rich
 
Old 07-10-2012, 07:16 AM
Ben de Groot
 
Default Portage Output / End User Experience

On 10 July 2012 09:41, Zac Medico <zmedico@gentoo.org> wrote:
> On 07/09/2012 06:11 PM, Rich Freeman wrote:
>> So, seems like there is still room for improvement...
>
> Aside from the obvious need to improve the portage behavior, we might
> also want to consider enabling USE=icu by default in the profile.

Enabling icu causes problems such as bug #413541. See also
https://bugs.gentoo.org/show_bug.cgi?id=425016#c5

Until the problems with icu are resolved, we (the Qt maintainers)
are opposed to enabling that useflag by default in profiles.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 07-10-2012, 07:25 AM
Ben de Groot
 
Default Portage Output / End User Experience

On 10 July 2012 11:03, Rich Freeman <rich0@gentoo.org> wrote:
> Yup, this issue hit anybody who has qt-webkit and chromium installed.
>
> I wouldn't be surprised if that is half of the entire userbase.

I would be.

> We ran into another confusing icu-related issue with qt-core a few
> weeks ago (bug 413541). I can understand that the qt maintainers want
> to get away from enabling icu for this reason, but chromium is a VERY
> popular package so it is really only disabled in the sense that it
> annoys a bazillion people who have to un-disable it and then still run
> into the problems.

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.

> Better portage logic might help here, but I think we need to consider
> whether a non-optimal decision from a single package perspective is
> going to lead to a better overall experience for our userbase. Zac
> suggested adding icu to the profile, which would work, though really
> just adding it as the default for these two packages would really
> address the issue until portage can catch up.
>
> Those who REALLY don't want icu support in qt-webkit can always
> disable it manually now that the flag is there. If there is a fear
> that this default will lead to more bugs, those bugs will happen
> anyway, since anybody running chromium has to enable that flag.

But for all we know, that is a minority of our users.

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.

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.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 07-10-2012, 11:18 AM
Rich Freeman
 
Default Portage Output / End User Experience

On Tue, Jul 10, 2012 at 3:25 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 10 July 2012 11:03, Rich Freeman <rich0@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
 
Old 07-10-2012, 12:34 PM
Michael Mol
 
Default Portage Output / End User Experience

On Tue, Jul 10, 2012 at 7:18 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Jul 10, 2012 at 3:25 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 10 July 2012 11:03, Rich Freeman <rich0@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.

Some ideas for reasonable statistic gathering:

* What's the user agent distribution for accessing bugs.gentoo.org?
* Which distfiles have been retrieved from mirrors most frequently?

UA stats from bugs.gentoo.org would be nicely biased towards Gentoo
users. As for distfile retrieval logs, you don't need data from all of
the mirrors, just the top 10% or so would likely be statistically
sufficient, even if you only have the HTTP retrievals, not the FTP
retrievals.

[snip the rest; I don't have a position or the expertise for
preferring any of the suggested technical solutions...]

--
:wq
 
Old 07-11-2012, 10:51 PM
Zac Medico
 
Default Portage Output / End User Experience

On 07/09/2012 06:05 PM, Zac Medico wrote:
> On 07/09/2012 05:58 PM, Zac Medico wrote:
>> On 07/09/2012 05:42 PM, Rich Freeman wrote:
>>> On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman <rich0@gentoo.org> wrote:
>>>> I'll test it out on a fresh install, but that will take a number of
>>>> hours
>>>
>>> If I install chromium first, I get the following messages when I try
>>> to install kde-meta:
>>> The following USE changes are necessary to proceed:
>>> #required by dev-db/virtuoso-server-6.1.4-r1, required by
>>> dev-libs/soprano-2.7.6[virtuoso], required by
>>> app-office/akonadi-server-1.7.2,
>>> required by kde-base/kdepim-runtime-4.8.3-r2, required by
>>> kde-base/kdepim-meta-4.8.3, required by
>>> kde-base/kde-meta-4.8.3[semantic-desktop], required by kde-meta (argument)
>>> =sys-libs/zlib-1.2.5.1-r2 minizip
>>> #required by x11-libs/qt-webkit-4.8.2[gstreamer], required by
>>> kde-base/kdebase-menu-icons-4.8.3, required by
>>> kde-base/kdebase-runtime-meta-4.8.3, required by
>>> kde-base/kdebase-startkde-4.8.3, required by kde-base/kdebase-meta-4.8.3,
>>> required by kde-base/kde-meta-4.8.3, required by kde-meta (argument)
>>> =dev-libs/libxml2-2.8.0_rc1 -icu
>>>
>>> You'll note that in this case there is nothing to suggest simply
>>> enabling icu for qt-webkit.
>>>
>>> If I emerge kde-meta first then I get the following when I try to
>>> emerge chromium:
>>> The following USE changes are necessary to proceed:
>>> #required by www-client/chromium-20.0.1132.43, required by
>>> chromium (argument)
>>> =dev-libs/libxml2-2.8.0_rc1 icu
>>>
>>> Then if I set the icu use flag on libxml2 it works. Apparently it
>>> doesn't realize that I'm about to break qt-webkit. Portage doesn't
>>> check use dependencies on existing packages when you go to rebuild
>>> something?
>>
>> Not unless the --complete-graph option is enabled. What I'd like to do
>> is to automatically enable --complete-graph mode whenever the USE of an
>> installed package would change. It would be like that
>> --complete-graph-if-new-ver option which is already enabled by default,
>> but it would apply to USE instead of versions.
>
> Bug filed:
>
> https://bugs.gentoo.org/show_bug.cgi?id=425558
>

Here's another related bug report, specifically about the solving the
libxml2/qt-webkit/chromium conflict:

https://bugs.gentoo.org/show_bug.cgi?id=426222

--
Thanks,
Zac
 
Old 07-12-2012, 04:17 AM
Ben de Groot
 
Default Portage Output / End User Experience

On 12 July 2012 06:51, Zac Medico <zmedico@gentoo.org> wrote:
>
> Here's another related bug report, specifically about the solving the
> libxml2/qt-webkit/chromium conflict:
>
> https://bugs.gentoo.org/show_bug.cgi?id=426222
>
> --

Actually, there is another workable solution, and that is to set
USE="-gstreamer -icu" for qt-webkit.

Currently we enable gstreamer by default in the ebuild (as it
is used for HTML5 audio/video, which is expected functionality
in qt-webkit based web browsers etc.), but we are considering
if we should perhaps not enable this by default.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 07-12-2012, 09:52 AM
Rich Freeman
 
Default Portage Output / End User Experience

On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> Actually, there is another workable solution, and that is to set
> USE="-gstreamer -icu" for qt-webkit.
>
> Currently we enable gstreamer by default in the ebuild (as it
> is used for HTML5 audio/video, which is expected functionality
> in qt-webkit based web browsers etc.), but we are considering
> if we should perhaps not enable this by default.

As discussed on the bug, this will likely help some, but it doesn't
help anybody who uses KDE or Gnome.

I'd normally suggest a news item, and that would make sense BEFORE
making changes like this, but at this point it is a bit like fixing
the doors after the horses have already left. It won't even help new
users much - their difficulty will be getting these packages
installed, so unless we just broadcast it to everybody just in case
they want to install qt and chromium, it isn't going to be effective.

We almost need some kind of news mechanism for people who are about to
install something.

Rich
 
Old 07-12-2012, 11:41 AM
Ben de Groot
 
Default Portage Output / End User Experience

On 12 July 2012 17:52, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> Actually, there is another workable solution, and that is to set
>> USE="-gstreamer -icu" for qt-webkit.
>>
>> Currently we enable gstreamer by default in the ebuild (as it
>> is used for HTML5 audio/video, which is expected functionality
>> in qt-webkit based web browsers etc.), but we are considering
>> if we should perhaps not enable this by default.
>
> As discussed on the bug, this will likely help some, but it doesn't
> help anybody who uses KDE or Gnome.

As far as I know the gstreamer useflag is only enabled in the gnome
profile, not the kde one currently.

Once we decide on this, I will add it to the Qt FAQ (now on the wiki)
and make an announcement on the forums.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 

Thread Tools




All times are GMT. The time now is 04:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org