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 1O5v9T-0001Lw-BL for garchives@archives.gentoo.org; Sun, 25 Apr 2010 06:17:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68B89E0793; Sun, 25 Apr 2010 06:17:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8DD14E0662 for ; Sun, 25 Apr 2010 06:16:30 +0000 (UTC) Received: from [192.168.22.2] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 1F09C1B404D for ; Sun, 25 Apr 2010 06:16:30 +0000 (UTC) Message-ID: <4BD3DE48.1050306@gentoo.org> Date: Sat, 24 Apr 2010 23:16:40 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100419 Thunderbird/3.0.4 ThunderBrowse/3.2.6.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass References: <4BB536DC.8090405@gentoo.org> <4BBB7FDE.7090306@gentoo.org> <4BC3A301.3040400@gentoo.org> <20100416212806.7bc6b307@snowmobile> <20100418084502.49030e16@snowmobile> <20100419214617.GA23143@boostbox> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 30ff5d72-7cc6-4f91-81b3-497c36a0fc92 X-Archives-Hash: 91a41e6b82ce02deb79c4c619ad2de76 On 04/23/2010 08:14 AM, James Cloos wrote: >>>>>> "HvD" =3D=3D Harald van D=C4=B3k writes: >=20 > HvD> Let's say this is in the tree: >=20 > HvD> foo.eclass: > HvD> DEPEND=3D"dev-lang/python:2.6" >=20 > HvD> bar-1.ebuild: > HvD> inherit foo >=20 > HvD> Let's say this is in your overlay: >=20 > HvD> foo.eclass: > HvD> DEPEND=3D"|| ( dev-lang/python:3.1 dev-lang/python:2.6 )" >=20 > HvD> Now you install bar. How should portage know that it must regenera= te the > HvD> metadata cache, to see that it doesn't need to install python 2.6 = if you > HvD> already have 3.1? >=20 > It shouldn't bother. :) >=20 > Really, that isn't the kind of change that I find I need to make. Different users have different needs. The user who reported this bug needed the opposite behavior: http://bugs.gentoo.org/show_bug.cgi?id=3D276264 > And it should never regenerate the metadata cache (ie portage/metadata/= cache). Again, different users have different needs and the user in bug #276264 really needed to regenerate the cache. > The docs used to -- and probably still do -- recommend regenerating tha= t > cache after certain changes. Which is a drasticly bogus suggestion unl= ess > you have a *very* fast system. It's a somewhat bogus suggestion if you are not modifying eclasses in the same way as the user from bug #276264. Note that it's possible to enable eclass-overrides without discarding $PORTDIR/metadata/cache. It seems like that might work for your use case (don't forget that this won't necessarily be appropriate for every user). For the user in bug #276264, it's more appropriate to discard $PORTDIR/metadata/cache and run emerge --regen (with --jobs if he wants to use multiple cpu cores in parallel). > Even across a dialup straw, an emerge --sync > is orders of magnitude faster. Different things give different results. It may work for your use case but not for others. > If the ebuild calls a class which has been overridden by a local class,= and > the original class set DEPENDs or the like, then as it reads in the new= class > file it should just use those values in place of the ones in the cache. And that's the behavior that you'll get if you don't discard $PORTDIR/metadata/cache (which would be inappropriate for the user in bug #276264). >=20 > -JimC --=20 Thanks, Zac