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 1LWHuR-000663-9h for garchives@archives.gentoo.org; Sun, 08 Feb 2009 22:13:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0E9FFE0403; Sun, 8 Feb 2009 22:13:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C86E3E0403 for ; Sun, 8 Feb 2009 22:13:48 +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 4C95D65124 for ; Sun, 8 Feb 2009 22:13:48 +0000 (UTC) Message-ID: <498F5932.505@gentoo.org> Date: Sun, 08 Feb 2009 14:14:10 -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> <1234080464.24784.2517.camel@localhost> <498E9EFE.2030807@gentoo.org> <1234093879.24784.2819.camel@localhost> <498F423A.8040604@gentoo.org> <1234129737.18160.191.camel@localhost> In-Reply-To: <1234129737.18160.191.camel@localhost> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b377e025-1a23-498f-b90b-31ffff30c5cb X-Archives-Hash: 94a65c9f395706a112ec903b611aad0e -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tiziano M=C3=BCller wrote: > Am Sonntag, den 08.02.2009, 12:36 -0800 schrieb Zac Medico: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tiziano M=C3=BCller wrote: >>> But if your target is to reduce the size of the metadata cache, why >>> store the hashes of the eclasses in the ebuild's metadata and not in = a >>> seperate dir? They have to be the same for every ebuild, don't they? >>> In case you have an average number of eclasses which is bigger than 4= , >>> you can even store the full hash with less space used than with >>> truncated hashes for all eclasses. >> The problem with having eclass integrity data shared in a separate >> file is that it creates a requirement for all cache entries which >> reference the same eclasses to be consistent with one another. This >> means that a single cache entry can no longer be updated atomically. >> For example, before updating the shared eclass integrity data, you'd >> want to make sure that you first discard all of the cache entries >> which reference it. Although it can be done this way, I think it's >> much more convenient to have all of the integrity data encapsulated >> within each individual cache entry. > Ok, let me see if I get this: Since parts of the content of a > metadata-entry (like the DEPEND/RDEPEND vars) depend on the contents of > the eclass used by the time a cache entry got generated, you want to > store the eclass' hash in the ebuild entry to make sure the entry gets > invalidated once the eclass changes. Is that correct? Right. By having each cache entry encapsulate it's own integrity data, the program updating the cache is never required to update more than one file at a time. Having shared integrity data would imply that the program would have the burden of maintaining consistency across all cache entries. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmPWTEACgkQ/ejvha5XGaOLHQCg0wGuRIkPCmQUQ2k14RjQlpv0 C54AoNqBaA6d3xyO6FuNz1GO7ZJ7y7E6 =3DD/ei -----END PGP SIGNATURE-----