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 1LYrkA-00045N-KS for garchives@archives.gentoo.org; Mon, 16 Feb 2009 00:53:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69F1FE0420; Mon, 16 Feb 2009 00:53:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 43C01E0420 for ; Mon, 16 Feb 2009 00:53:53 +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 A9637B4E97; Mon, 16 Feb 2009 00:53:52 +0000 (UTC) Message-ID: <4998B94C.4000301@gentoo.org> Date: Sun, 15 Feb 2009 16:54:36 -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: Zac Medico CC: 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> <4998B7EC.7040101@gentoo.org> In-Reply-To: <4998B7EC.7040101@gentoo.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: f006e17e-9b02-4480-951a-dfa9661fa478 X-Archives-Hash: 4aebcea455a6c9c005a3101c5ad8d0b8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zac Medico wrote: > Ciaran McCreesh wrote: >> On Sun, 15 Feb 2009 15:56:18 -0800 >> 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). Well, I guess you were saying that it should just use the EAPI. Given that we don't have much control over how often users upgrade, I'd still prefer to have a DIGESTS version identifier. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYuUsACgkQ/ejvha5XGaOIcQCfctQ/heCKDzGmls3NNLulodsD g2AAnAwOd/JD+sHvDBPQSmx2LOHOiqjw =onL8 -----END PGP SIGNATURE-----