From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 3E7D0138838 for ; Sun, 3 Feb 2013 23:22:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0AF1D21C09C; Sun, 3 Feb 2013 23:22:42 +0000 (UTC) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37E12E06B1 for ; Sun, 3 Feb 2013 23:22:40 +0000 (UTC) Received: by mail-gh0-f172.google.com with SMTP id z22so1394900ghb.17 for ; Sun, 03 Feb 2013 15:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=cguyydLWRZX+z+tKOTV4N495Byu0OZ65r+54rQdA3ms=; b=jRDMPUCKaQSbUHL4M+0mTWmzctyRJuDT3t/sWrS6Iu7RbFgHniUMmr+2ut+CgYFcnf XJLiy1lVI7n+7hxmSLzEyY2D6od8R/xEMt7dblABINo/fUkWeW3o7b6R6dKXZAI5LSmp uGKm4NYdBckfbrQnUaGKKpG3e/zG2wpISgWVrTflCxFztO8b1owcR00Cf/3dY5+rM28Q ZDqwd8rcnSB8QYwaBpYTp/7KZaqiNnd/M4pYPTAD0/z9fqsG9cm6OAxMIr2VUFOhjEcz 2z/aAD54vi5B5TLOLNLMj/JIgnQ4aCUTYoo++0/dIxag+QDdEZUyAqieoUvC4xC/QDZ0 RkRw== X-Received: by 10.236.46.169 with SMTP id r29mr23861698yhb.14.1359933759266; Sun, 03 Feb 2013 15:22:39 -0800 (PST) Received: from [192.168.2.5] (adsl-74-240-57-140.jan.bellsouth.net. [74.240.57.140]) by mx.google.com with ESMTPS id k24sm26170384yhd.5.2013.02.03.15.22.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Feb 2013 15:22:38 -0800 (PST) Message-ID: <510EF13C.5020905@gmail.com> Date: Sun, 03 Feb 2013 17:22:36 -0600 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Confusing emerge output References: <510EB1B9.3090607@gmail.com> <510EB602.4000805@gmail.com> <510ED509.2000102@gmail.com> In-Reply-To: <510ED509.2000102@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2ecf18c3-54ae-4515-b0d4-cc4bc6835171 X-Archives-Hash: 8e93c9df6caa3bdf1a4216c16e3fe2d7 Alan McKinnon wrote: > On 03/02/2013 21:09, Dale wrote: >> Alan McKinnon wrote: >>> emerge -e --keep-going @world >>> shows output like this when a build fails: >>> >>> * One or more packages are either masked or have missing dependencies: >>> * >>> * >=dev-libs/icu-49:0/50= pulled in by: >>> * (x11-libs/qt-core-4.8.4-r1::gentoo, installed) >>> >>> I can't parse that. What kind of SLOT is "0/50=" ? >>> >>> So far this has happened twice. The packages that failed prior are not >>> important, >>> what is important is that when the depgraph is *recalculated*, I get >>> that error. >>> It's always that specific atom for icu causing issues and it's always >>> pulled in >>> by qt- >>> >>> Anyone know what that atom means and if it's a bug or not? >>> >>> This system is ~amd64 and portage is latest masked 2.2.0_alpha161. >>> Active python is 2.7 >>> >> >> LOL I'll give this a go, sort of. I get this for icu: >> >> root@fireball / # equery l -p icu >> * Searching for icu ... >> [IP-] [ ] dev-libs/icu-49.1.2:0 >> [-P-] [ ~] dev-libs/icu-50.1-r1:0/50.1 >> [-P-] [ ~] dev-libs/icu-50.1-r2:0/50.1 >> [-P-] [ ~] dev-libs/icu-50.1.1:0/50.1.1 >> root@fireball / # >> >> So, does it maybe want icu-50.* instead of the 49 that is installed? >> That would be equal to or greater than what you likely have. I might >> add, the 50 and above are keyworded. >> >> I took a stab at it but not sure what I hit. ;-) > It's confusing, lemme see if I can describe it, using the URL that > Michel O posted. > > Your eix shows 4 versions of icu. Everything there up to the "/" chars > is normal and what you've been using for ages. > > The "/" is sub-slots, introduced in EAPI=5. icu-49 uses a lesser EAPI so > it has no sub-slots. Each icu version >=50 is in SLOT 0, and it will > install .so files with the version after the "/". > > So take my icu for example, it's version 50.1.1 and equery files reveals > it installs: > > /usr/lib64/libicui18n.so.50.1.1 > /usr/lib64/libicuio.so.50.1.1 > /usr/lib64/libicule.so.50.1.1 > > Well whaddaya know, the .so version matches what eix claims (meaning the > icu ebuild is correctly declaring what it will provide). > > That's one half of the story, the other half is with packages that > DEPEND on icu. qt-core for example has this: > > icu? ( >=dev-libs/icu-49:= ) > > Now what that means is "qt-core DEPENDS on any version of icu >49, plus > the following: (this is the bit that's gonna bake your noodle) > > If icu is re-emerged and that new version has a different .so version to > what the current version provides, then qt-core will break at run-time. > That's what the trailing = means, ie. qt-core depends on an icu that has > an soname equal to the one it has right now. In my case that is 50.1.1. > If I upgrade icu to a version with a different soname, then qt-core has > to be rebuilt, and now portage knows that. > > There's another operator that can go where the "=" is and it's "*". > Which basically means "any". So if I have some package using EAPI=5 and > it has this line in DEPENDS: > > icu? ( >=dev-libs/icu-49:* ) > > Then that would mean it depends on >icu-49 and the soname doesn't matter > as it can be any version. Presumably the devs did their homework and > figured out what their packages depend on, then put the right info in > their ebuilds. (I fear this last might be a tall order, but hey, we're > discussing syntax here, not human ability) > > Is this all starting to sound maybe just a little bit like some magic > that will make @preserved-rebuild and revdep-rebuild redundant? We need > those tools because portage does not know what so versions will work > fine with what, and these sub-slots are supposed to give portage that > info. Whoopee. > > ;-) > > Clear as mud now? > > < Dale scratches head > Hmmmm, that mud is pretty thick. May have to let that one sit for a bit to settle out. ^-^ So, portage is getting smarter about breakages then? Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!