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 1LYr0Z-0007bT-39 for garchives@archives.gentoo.org; Mon, 16 Feb 2009 00:06:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B1259E031A; Mon, 16 Feb 2009 00:06:45 +0000 (UTC) Received: from mail-ew0-f15.google.com (mail-ew0-f15.google.com [209.85.219.15]) by pigeon.gentoo.org (Postfix) with ESMTP id 5E351E031A for ; Mon, 16 Feb 2009 00:06:45 +0000 (UTC) Received: by ewy8 with SMTP id 8so1740387ewy.10 for ; Sun, 15 Feb 2009 16:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=K4zcLRvMDhaIwMPxxXx3msLDR2SZZ5tzrre0GCSoSUU=; b=geoc7EQMRvc2JDIswoTa+VOif5DWm7OE/+5bBB0l+pthb+WMHzGiwYPIJHurXSWL0J 7ZVAA1DvIZ7bbf2LRgdr9ZS51OoUTLK6C+t82jkOAQfbXo5vlryBqepybUNCjKZrTAwE d8N95thWU5NL3/jM7c9ipoKrnCTRocTNzzaJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=xjBxPiNILWgRJErstTYxSRsngqAqGXb9ory384JOi9bA/4L9afArkoFpN7PF+oCcaq KIueV8hQEv0W+uB9ycJ2PS0ltO9aK1Fq+bsauRFSnW9D3b7LxaPxLzf14ad/DJk8Fy38 6obmPkHJOzdpXNMjlfrd8W9kM9/LifUyuQDPo= Received: by 10.210.58.13 with SMTP id g13mr3226886eba.33.1234742804620; Sun, 15 Feb 2009 16:06:44 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 28sm11033881eyg.55.2009.02.15.16.06.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Feb 2009 16:06:44 -0800 (PST) Date: Mon, 16 Feb 2009 00:06:36 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation Message-ID: <20090216000636.1087b1c2@snowcone> In-Reply-To: <4998ABA2.20908@gentoo.org> References: <498758E6.5080609@gentoo.org> <1234045916.24784.1373.camel@localhost> <498E17E6.8060407@gentoo.org> <49989C5E.3020307@gentoo.org> <20090215231527.3dbc2cb6@snowcone> <4998A4B4.4050802@gentoo.org> <20090215233033.3b534f54@snowcone> <4998ABA2.20908@gentoo.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; boundary="Sig_/GvOxpinmw_wc4MK1wXPcBme"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 4071208a-b8f0-403d-a1f2-9d610871f58c X-Archives-Hash: 060c45dba0a59b24deaa42b136826d9a --Sig_/GvOxpinmw_wc4MK1wXPcBme Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 15 Feb 2009 15:56:18 -0800 Zac Medico wrote: > If the package manager is not able to validate a cache entry that > has been generated for an unsupported EAPI, then it will be forced > to regenerate the metadata in order to check whether or not the EAPI > has changed (example given 2 emails ago). Don't you agree that it > would be useful to be able to avoid metadata generation in cases > like this, if possible? Well... The solution you give only *sometimes* avoids it, so it's only worth it if we expect that most EAPI changes won't mess around with inheriting at all. And given that we probably want per-cat/pkg eclasses... It only comes into its own if you expect there to be a long time between an EAPI being used in the tree and an EAPI being supported by a package manager. And even then, it's probably easier to just do a minor stable release straight away with rules for "don't know how to use this EAPI, but do know how to read metadata cache entries for it" whilst keeping new EAPI support for the next major release. Honestly, I don't think it'll be useful often enough that it's worth the added ick. --=20 Ciaran McCreesh --Sig_/GvOxpinmw_wc4MK1wXPcBme Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYrg8ACgkQ96zL6DUtXhG7NACgpfItK1Avz7D9n1tsPrcfrcVH BCsAoOESrfs6vHOTPBV12r/I2a9pYs9h =yz8E -----END PGP SIGNATURE----- --Sig_/GvOxpinmw_wc4MK1wXPcBme--