From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LUp0U-0003vV-6m for garchives@archives.gentoo.org; Wed, 04 Feb 2009 21:10:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B220E06A2; Wed, 4 Feb 2009 21:10:01 +0000 (UTC) Received: from mail-ew0-f14.google.com (mail-ew0-f14.google.com [209.85.219.14]) by pigeon.gentoo.org (Postfix) with ESMTP id 9F031E06A2 for ; Wed, 4 Feb 2009 21:10:00 +0000 (UTC) Received: by ewy7 with SMTP id 7so48959ewy.10 for ; Wed, 04 Feb 2009 13:10:00 -0800 (PST) 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:content-disposition:message-id; bh=dYLx05Rz3G9ExJNrWwCQKxG5x+u+YhEIcq03z4QtgYY=; b=W9W5CxPanHjEcMot9C7yj8hQF0j0hG6ZOGSH2EaqbIoRTU7tVLS332xf5pv8RaYQlH azrk3KITC9Yh+ugFHaXvmvDQlrElkkTrCfUejxbQ5jmh4zgUjt2QQqvkIhRBK+i9TqDA gOPwNNRWaRvxe4NjECV0+9xFkTmRtEgnjNvoU= 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:content-disposition :message-id; b=m0hKm9n2/CSAw+R+8YGLJT8runC/+91zssrAlyulgCmYFYUnyaYLKhoE2eEGLq050S kdHXLX4ojKcbVVm37uJk8O/iMEHSOiUVT4Bl4DqXx6pyB8Oocn43R4tWDE4RiGbbvlCp 73Ysfe4C4YsxZXHjug/VTLhxAtbnM9uLeEX0Q= Received: by 10.66.220.12 with SMTP id s12mr3842346ugg.22.1233781696584; Wed, 04 Feb 2009 13:08:16 -0800 (PST) Received: from ?172.20.0.5? (196-210-140-105-wblv-esr-3.dynamic.isadsl.co.za [196.210.140.105]) by mx.google.com with ESMTPS id g9sm4439447gvc.4.2009.02.04.13.08.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Feb 2009 13:08:16 -0800 (PST) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: libtool problem Date: Wed, 4 Feb 2009 23:07:09 +0200 User-Agent: KMail/1.9.10 References: <200902042221.38749.alan.mckinnon@gmail.com> <200902042140.33320.dirk.heinrichs@online.de> In-Reply-To: <200902042140.33320.dirk.heinrichs@online.de> 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-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902042307.09846.alan.mckinnon@gmail.com> X-Archives-Salt: 722ceaac-c34a-4211-9284-db58dad71fe9 X-Archives-Hash: fd657b918e196349f7766f99712167cf On Wednesday 04 February 2009 22:40:26 Dirk Heinrichs wrote: > Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon: > > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote: > > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD: > > > > The reason there wasn't a bump (IIRC) was that the ebuild never > > > > changed - only the eclass did. =A0If you emerged any version of GCC > > > > during the window where the eclass was broken, that version of GCC > > > > would have been broken. > > > > > > That also means that portage is broken. Whenever something changes > > > where other things depend on, those other things should be rebuilt. > > > This doesn't happen here. > > > > I disagree, that would cause many more spurious rebuilds than is needed > > if it were automated. > > Why spurious? The package manager should be smart enough to tell the user: > "Rebuild because of eclass change". Nothing spurious. Portage only knows that the eclass changed. It does not know what the resul= t=20 of that change will be. Therefore it is not in a position to mandate that a= =20 rebuild of other apps is *required* in order to function correctly. Which=20 leaves us with two options: Tell the user to look and decide for themselves, or Rebuild everything using the eclass anyway The latter option will always fix problems but at a huge cost of most often= =20 rebuilding something that looks like it needs rebuilding but actually=20 doesn't. Therefore spurious. > > Portage cannot tell how important or how deep a change > > is, that requires a human to look and see. So what is needed is a flag > > that portage recognizes as an instruction to do a revdep-rebuild-style > > search and find everything using a specific changed file, and rebuild > > those. The flag is set under dev control. > > Not dev, user. Something equivalent to --newuse. I was thinking more along the lines of what @preserved-rebuild does. Some=20 mechanism in the ebuild that includes a package in a list of stuff to be=20 rebuilt. Obviously this is something new and a fairly deep change to portag= e=20 so I can't think of a decent parallel or analogy. > > Blindly doing what you suggest leads to this: > > > > appA depends on libB. > > No. Sorry if this was misleading. I was only referring to dependencies > between ebuilds and eclasses. OK > Library interdependencies are handled just fine by portage/revdep-rebuild. > > > Therefore, a simple elog entry is a valid handling and fully compliant > > with the principle of The Simplest Thing That Could Possibly Work. > > Elog entries are overlooked too often. True, but do we have anything better? As in a proven mechanism successfully= =20 used elsewhere to deal with comparable situations? =2D-=20 alan dot mckinnon at gmail dot com