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 1LYreU-0003KC-SB for garchives@archives.gentoo.org; Mon, 16 Feb 2009 00:48:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9FAFE04A6; Mon, 16 Feb 2009 00:48:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 91189E04A6 for ; Mon, 16 Feb 2009 00:48:01 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 0E2B3B4EB4 for ; Mon, 16 Feb 2009 00:48:01 +0000 (UTC) Message-ID: <4998B7EC.7040101@gentoo.org> Date: Sun, 15 Feb 2009 16:48:44 -0800 From: Zac Medico User-Agent: Thunderbird 2.0.0.19 (X11/20081209) 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] [RFC] DIGESTS metadata variable for cache validation 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> <20090216000636.1087b1c2@snowcone> In-Reply-To: <20090216000636.1087b1c2@snowcone> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 9a90ca4a-9531-49bd-9948-6a67f4dd5159 X-Archives-Hash: 1ea63423fb03b81db2b8c322ae4f064b -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > 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... Well, I think it's more like "the vast majority of the time" than just "sometimes", and it's a lot better than "never". > 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. But how will it know if it supports those cache entries? Wouldn't the easiest way to determine that be to have a DIGESTS version identifier? Otherwise, the only way for it to know would be to parse it and either throw a parse error if necessary or proceed all the way to the digest verification step (if it doesn't hit a parse error first). > Honestly, I don't think it'll be useful often enough that it's worth > the added ick. Doesn't a simple version identifier seem less icky than checking for both a parse error and digest verification failure? - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYt+oACgkQ/ejvha5XGaOC6gCgzgIcH6D7X/o/vOuWvsS0mp42 dGsAn17xnY8bX9IG28Uj3MX42qdrxGrL =+Hkp -----END PGP SIGNATURE-----