Tags Tags

[gentoo-dev] Portage Output / End User Experience

July 09th, 2012 - 10:10 am ET by Rich Freeman | Report spam
Help Create a new topic
After a little discussion in bug 425016 [1], I did an experiment.

I created a fresh Gentoo install, set the profile to desktop/kde, and
tried to emerge chromium and kde-meta.
The immediate response was for portage to suggest setting -u and -N
due to conflicts.

So, I tried emerge -puDNv chromium kde-meta
That said I needed to enable minizip for zlib and icu for libxml2.

So, I did that via package.use, and tried again. Now I'm told:
The following keyword changes are necessary to proceed:
#required by dev-libs/libxslt-1.1.26-r3, required by x11-libs/libxcb-1.8.1,
required by x11-libs/xcb-util-0.3.9, required by
x11-libs/xcb-util-image-0.3.9
=dev-libs/libxml2-2.8.0-r1 ~amd64

The following USE changes are necessary to proceed:
#required by net-libs/libsoup-2.36.1-r1, required by
media-plugins/gst-plugins-soup-0.10.30, required by
media-libs/phonon-gstreamer-4.5.0[network], required by
media-libs/phonon-4.5.1-r1[gstreamer], required by kde-base/kdelibs-4.8.3,
required by kde-base/libkcompactdisc-4.8.3, required by
kde-base/kdemultimedia-meta-4.8.3, required by
kde-base/kde-meta-4.8.3, required
by kde-meta (argument)

=dev-libs/libxml2-2.8.0-r1 -icu



emerge: there are no ebuilds built with USE flags to satisfy
"dev-libs/libxml2:2[!icu?]".
!!! One of the following packages is required to complete your request:
- dev-libs/libxml2-2.7.8-r5::gentoo (Change USE: -icu)
- x11-libs/qt-webkit-4.8.2::gentoo (Change USE: +icu)

Now, a few interesting things here:
1. On my regular kde desktop I don't have an unstable version of
libxml2 - I'm not sure why I haven't gotten any complaints about that,
but I'm being told to unmask it in this case.
2. The first suggestion with libxml2 is to remove the icu flag, which
the previous step told me to add.
3. The very last line does get at what needs to be done here - enable
+icu on qt-webkit.

If I enable icu on qt-webkit only then it looks like it should work -
it no longer asks to unmask libxml2 or unset the icu use flag.

I realize that figuring out the right thing to do here isn't at all a
trivial matter. However, this seems like a fairly convoluted thing
for a new user who wants to run KDE and Chromium to go through. Those
are both VERY mainstream packages. Is there any way to improve the
portage logic to give better suggestions in this case, or some way to
otherwise point new users in the right direction?

Please note that I don't mean to pick on either qt or chromium
maintainers here - they've all done what seems most logical from the
standpoint of their own packages. However, it seems like the
combination is not going to be nice on new users.

It also seems like the current portage output is giving the user some
contradictory and counterproductive advice. It seems like there are
really only two possible choices
1. The user could choose to not install chromium.
2. The user could enable icu for qt-webkit.

Doing anything else is just going to lead to some kind of cycle of
errors until the user figures it out. Then they have to clear out
who-knows-what from /etc/portage as they blindly followed
instructions.

Is there any way for portage to figure out that one of those is the
eventual outcome, and then direct the user to the minimal changes to
accomplish either?

Rich

1 - https://bugs.gentoo.org/show_bug.cgi?idB5016
email Follow the discussionReplies 24 repliesReplies Make a reply

Similar topics

Replies

#1 Peter Stuge
July 09th, 2012 - 10:20 am ET | Report spam
Rich Freeman wrote:
It also seems like the current portage output is giving the user some
contradictory and counterproductive advice. It seems like there are
really only two possible choices
1. The user could choose to not install chromium.
2. The user could enable icu for qt-webkit.



Do you get the same suggestions from portage if you attempt emerge
kde and chromium one at a time?


//Peter
Replies Reply to this message
#2 Rich Freeman
July 09th, 2012 - 11:00 am ET | Report spam
On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge wrote:
Rich Freeman wrote:
It also seems like the current portage output is giving the user some
contradictory and counterproductive advice. It seems like there are
really only two possible choices
1. The user could choose to not install chromium.
2. The user could enable icu for qt-webkit.



Do you get the same suggestions from portage if you attempt emerge
kde and chromium one at a time?



I'll test it out on a fresh install, but that will take a number of
hours (a total of 694 packages between them, which will take a while
even on 4 cores, and warm up the office as well...). If I try to
start out with chromium first the initial suggestion is to enable icu
on libxml2, and if I try to start out with kde-meta the initial
suggestion is to enable minizip on zlib (unrelated to this whole
issue).

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.

Let me give that upgrade a try both ways, but it might take a few days
to have all the results of that.

Rich
Replies Reply to this message
#3 Michael Mol
July 09th, 2012 - 11:10 am ET | Report spam
On Mon, Jul 9, 2012 at 10:56 AM, Rich Freeman wrote:
On Mon, Jul 9, 2012 at 10:11 AM, Peter Stuge wrote:
Rich Freeman wrote:
It also seems like the current portage output is giving the user some
contradictory and counterproductive advice. It seems like there are
really only two possible choices
1. The user could choose to not install chromium.
2. The user could enable icu for qt-webkit.



Do you get the same suggestions from portage if you attempt emerge
kde and chromium one at a time?



I'll test it out on a fresh install, but that will take a number of
hours (a total of 694 packages between them, which will take a while
even on 4 cores, and warm up the office as well...). If I try to
start out with chromium first the initial suggestion is to enable icu
on libxml2, and if I try to start out with kde-meta the initial
suggestion is to enable minizip on zlib (unrelated to this whole
issue).

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.

Let me give that upgrade a try both ways, but it might take a few days
to have all the results of that.



When tracking down why glibc updates were killing my systems, I wrote
an install script to accelerate the install-update-fail-retry cycle.
You may find it useful:

https://github.com/mikemol/gentoo-install

It shouldn't require *too* much modification to automate what you're
trying to test. I intend to modify it to work in chroot environments,
as a prelude to some build-related bug reports I'm sitting on.

:wq
Replies Reply to this message
#4 Rich Freeman
July 09th, 2012 - 11:50 am ET | Report spam
On Mon, Jul 9, 2012 at 11:04 AM, Michael Mol wrote:
It shouldn't require *too* much modification to automate what you're
trying to test. I intend to modify it to work in chroot environments,
as a prelude to some build-related bug reports I'm sitting on.



Thanks - seems useful in general. Not sure I'll use it for this - a
chroot should be adequate to test this (I don't intend to actually run
KDE), and is much more efficient with CPU/RAM/etc.

One thing I did set up for doing VM installs of Gentoo is a PXE
enviornment that runs with an NFS root. I can stick stuff like
stage3s and portage snapshots and template config files on that NFS
root easily, and update it when necessary (though really the install
image really only needs to be updated to address hardware, which isn't
a big deal with VMs). It isn't anything too exciting, but maybe I
should write up a howto - there may already be some Gentoo PXE guides
already and any of those should basically work.

Rich
Replies Reply to this message
#5 Maxim Kammerer
July 09th, 2012 - 12:40 pm ET | Report spam
On Mon, Jul 9, 2012 at 6:41 PM, Rich Freeman wrote:
Thanks - seems useful in general. Not sure I'll use it for this - a
chroot should be adequate to test this (I don't intend to actually run
KDE), and is much more efficient with CPU/RAM/etc.



Liberté Linux build scripts do a complete build-from-scratch in a chroot:

https://github.com/mkdesu/liberte/b...ter/mkroot
https://github.com/mkdesu/liberte/b...root/setup

"build" is the top-level script, mastering a read-only deployment
image, but mkroot+setup suit the purpose of testing / deploying a
fresh Gentoo build.

Maxim Kammerer
Liberté Linux: http://dee.su/liberte
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search