From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MlML1-0006AZ-QS for garchives@archives.gentoo.org; Wed, 09 Sep 2009 12:31:53 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E13BE0824; Wed, 9 Sep 2009 12:31:48 +0000 (UTC) Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by pigeon.gentoo.org (Postfix) with ESMTP id 27859E0824 for ; Wed, 9 Sep 2009 12:31:48 +0000 (UTC) Received: by ywh27 with SMTP id 27so7284808ywh.2 for ; Wed, 09 Sep 2009 05:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=G69S7LJIjtI5X1CW00eyrqh0Lh9j+XsBfzpcbyeTS28=; b=QfdnI0Os7Q1Qa8OoADF9IYuvrEFCO8cQ1Ely/LENNbajWswd90HIFsp+kF2aDmKINK FAS0tl/lyl8RzJoUkCO6kyloy/QQ6GoSGjXu0URWaria3fEcA5njH9nTVOQUR2VnRm9m 715FcLxB8lZS3dOVF2CKBR3//FLGjjBy3r3wE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=HiU1JxjXXc7hvbJq3aJeGrrJ3K+fc2i3y95EBuCKlTxZm3JvYMBdterpTMxmNBxm1E ikL++BdZUsySUGdYx5rPvSO0i1SCpYNksGneDIdUOg2dJVluyBWTc7VjizTKXSu9eNTA tTEylTYVh+ILhXyAE2CVHsbL0gmDZ0+s9g4mc= Received: by 10.90.154.4 with SMTP id b4mr122391age.84.1252499507804; Wed, 09 Sep 2009 05:31:47 -0700 (PDT) Received: from nazgul.localnet (196-210-140-68-rrdg-esr-2.dynamic.isadsl.co.za [196.210.140.68]) by mx.google.com with ESMTPS id 38sm1558245agd.76.2009.09.09.05.31.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Sep 2009 05:31:46 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] --depclean and python needed by scribus. Date: Wed, 9 Sep 2009 14:30:14 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30-gentoo-r6; KDE/4.3.1; x86_64; ; ) References: <4AA794D1.10104@gmail.com> In-Reply-To: <4AA794D1.10104@gmail.com> 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 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909091430.14574.alan.mckinnon@gmail.com> X-Archives-Salt: 5d4a8836-866d-4a79-8989-1cd6015ba8b7 X-Archives-Hash: be8110008ad14bc53640ddf5ad615445 On Wednesday 09 September 2009 13:43:13 Dale wrote: > Hi folks, > > Can someone tell me what this means? > > root@smoker / # emerge -p --depclean > > * Always study the list of packages to be cleaned for any obvious > * mistakes. Packages that are part of the world set will always > * be kept. They can be manually added to this set with > * `emerge --noreplace `. Packages that are listed in > * package.provided (see portage(5)) will be removed by > * depclean, even if they are part of the world set. > * > * As a safety measure, depclean will not remove any packages > * unless *all* required dependencies have been resolved. As a > * consequence, it is often necessary to run `emerge --update > * --newuse --deep @system @world` prior to depclean. > > Calculating dependencies... done! > > >>> Checking for lib consumers... > >>> Assigning files to packages... > > * In order to avoid breakage of link level dependencies, one or more > * packages will not be removed. This can be solved by rebuilding the > * packages that pulled them in. > * > * dev-lang/python-2.5.4-r3 pulled in by: > * app-office/scribus-1.3.3.11 > * > > >>> Adding lib providers to graph... > > \ > Calculating dependencies... done! > > > I have re-compiled scribus about three times now. I have also ran > python-updater a few times and it just keeps rebuilding scribus and > boost in a endless loop. What am I missing here? This is horrible to solve. I'll tell you what I've discovered when it happens to me. But first, the error message is generic and a best guess - "rebuilding the packages that pulled them in" might work, but also might not. The superficial problem is broken ebuilds caused by the real problem - broken build scripts that configure themselves in funky ways at build time. Real example, I have this on my machine: * dev-db/edb-9999 pulled in by: * media-libs/imlib2_loaders-9999 and nazgul mysql # eix imlib2_loaders [I] media-libs/imlib2_loaders [1] Installed versions: 9999(18:33:40 09/06/09)(-doc -edb -nls) and # ldd /usr/lib64/imlib2/loaders/*.so | grep edb libedb.so.1 => /usr/lib/libedb.so.1 (0x00007f33bf139000) So, edb is nowhere in the dependency graph for imlib2_loaders (USE=-edb). Portage *knows* it should not depend on edb at all. But, when imlib2_loaders builds, ./configure finds edb on the system (I have it, I just don't want support for it in imlib2_loaders). The ./configure is broken - there is no "--enable edb" in it. Now this always just happened to work just fine for all of us. Recent portage know records link level deps when it builds stuff (see ldd above) so now concludes (correctly) that imlib2_loaders does not depend on edb per portage, but does per the actual system. It is now clear that I now have two and only two options: - Unmerge edb. This might not be desirable and I should not be forced to do this. - Build imlib2_loaders with edb support. This also might not be desirable. Actually there's a third option: fix the e17 team's broken build scripts. In your case, I think you need to rebuild scribus with "USE=python" Note that portage can't really help you diagnose these issues, it can only point them out. It has no idea that the inconsistency is due to that USE flag (it can't read human-speak). You also can't DEPEND on scribus[python] as 1. The dep is the wrong way round 2. It's actually force USE=python for scribus if, and only if, python is actually already present on the system. This is also the wrong way round and portage should not be expected to implement funky run-time detection workarounds for broken ./configure scripts. I did tell you at the beginning that it was complex, right? -- alan dot mckinnon at gmail dot com