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 1LWcbQ-0000h7-DI for garchives@archives.gentoo.org; Mon, 09 Feb 2009 20:19:36 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58CFDE053D; Mon, 9 Feb 2009 20:19:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3256CE053D for ; Mon, 9 Feb 2009 20:19:35 +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 C8E95B47BE for ; Mon, 9 Feb 2009 20:19:34 +0000 (UTC) Message-ID: <49908FE6.3040402@gentoo.org> Date: Mon, 09 Feb 2009 12:19:50 -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> <20090208221814.722f573a@snowmobile> <498F5FF5.50203@gentoo.org> <20090208224721.4193ca45@snowmobile> <498F64D4.4080303@gentoo.org> <20090208231010.4b2ebe3b@snowmobile> <498F6A7A.2060408@gentoo.org> <20090208233008.6350dd40@snowmobile> <498F6D60.7080500@gentoo.org> <49902202.1080607@gentoo.org> In-Reply-To: <49902202.1080607@gentoo.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 05629a26-847a-4903-92d2-60e8ad314952 X-Archives-Hash: 520a01f6a16d6de26f0e5a6c003fc385 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Petteri R=C3=A4ty wrote: > Zac Medico wrote: >> Ciaran McCreesh wrote: >>> On Sun, 08 Feb 2009 15:27:54 -0800 >>> Zac Medico wrote: >>>>> Which is offset and more by the massive inconvenience of having to >>>>> keep track of and store junk under version control. >>>> I think you're making it out to be worse than it really is. Like I >>>> said, I think we have a justifiable exception to the rule. >>> If you start encouraging this approach, are you prepared to make >>> Portage warn extremely noisily if a repository-provided (as opposed t= o >>> user generated) cache entry is found to be stale? >> Sure. Otherwise, it's confusing for the user when dependency >> calculations take longer than usual for no apparent reason. >> >=20 > It would probably be useful to provide a central rsync infra for > overlays where overlay maintainers could subscribe their overlays to an= d > the machine would pull in their VCS and generate the metadata for them. That's fine if somebody wants to implement it. The introduction of DIGESTS data in the metadata cache does not preclude it. Like I just said in another reply [1], the ability to distribute cache via a vcs is only an ancillary feature which is made possible by the DIGESTS data. [1] http://archives.gentoo.org/gentoo-dev/msg_760e199e74796fed7e56236f248efe9= e.xml - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmQj+UACgkQ/ejvha5XGaOajACePIoV6STCE/bh7SB8X/ch4phk bpAAnjsYR9UgBVP26wIldvCX2OFNe4yy =3DkYc/ -----END PGP SIGNATURE-----