From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NDvtJ-0006DI-0m for garchives@archives.gentoo.org; Fri, 27 Nov 2009 08:09:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6160FE0821; Fri, 27 Nov 2009 08:08:12 +0000 (UTC) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by pigeon.gentoo.org (Postfix) with ESMTP id 3FA85E0821 for ; Fri, 27 Nov 2009 08:08:12 +0000 (UTC) Received: by ywh17 with SMTP id 17so1304044ywh.2 for ; Fri, 27 Nov 2009 00:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=UN2BL/VeFgbz9ig3TW1yA8lmKHaQjqcvtvBnB7sOT84=; b=CCpRwffBlw+iT949CkT8eRdT9SA1Q/Z3fUVAz4crqNuVf5t+gLXf+j4NhP5/G6/AS1 MxutOvBM5gJSn2+MwS2yMUp6r/shwpC3nxirdqDti1KYsxSz6YN1MPCboHKcRnt15lR3 QYHfW2VW9c3u7eF1+l0giyBz6vZX1HunI9LPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZXjCsT1re+Mf0NgsDrBwJrDdzVCFkexKsZKhQ7dOhjmlHE6s0vdsWO4FBgWa4yR/Mw tacfBl/yPuGejhkaq13Z+lNtJDzConsKvo2+VD8r+tYr6PsH+AcO3nGLkuuQgJagoDrh 124HGymJpWBlvzGN9A2VnT2vJrWOQXpbCfRZE= Received: by 10.90.166.2 with SMTP id o2mr1022517age.93.1259309291826; Fri, 27 Nov 2009 00:08:11 -0800 (PST) Received: from smtp.gmail.com (c-98-210-130-131.hsd1.ca.comcast.net [98.210.130.131]) by mx.google.com with ESMTPS id 7sm718178yxg.68.2009.11.27.00.08.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 00:08:10 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 27 Nov 2009 00:08:07 -0800 Date: Fri, 27 Nov 2009 00:08:07 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC Message-ID: <20091127080807.GE6082@hrair> References: <7c612fc60911251350k3560b7d7sf4e9c867a30b0d90@mail.gmail.com> <20091126013438.GF23443@hrair> <20091126153117.7c8dd725@snowcone> <20091126163302.GD6082@hrair> <20091126164649.780f491c@snowcone> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+JUInw4efm7IfTNU" Content-Disposition: inline In-Reply-To: <20091126164649.780f491c@snowcone> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 9549874e-6ba8-4700-93e6-f29ff2974205 X-Archives-Hash: 3dad7c2ac29194a0d1a3b2f70e73c813 --+JUInw4efm7IfTNU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 26, 2009 at 04:46:49PM +0000, Ciaran McCreesh wrote: > On Thu, 26 Nov 2009 08:33:03 -0800 > Brian Harring wrote: > > > "Provide proof that all existing and future caches that would rely > > > upon this validation mechanism are functions purely and exclusively > > > dependent upon the VDB content, and I shall be happy to make the > > > change." > > The timestamp updating is for whenever the vdb content (addition of a= =20 > > pkg, pkgmoves being applied, removal of a pkg, modification of=20 > > metadata, etc) is changed. That's all that timestamp is for. Vdb=20 > > content. > >=20 > > In light of what the timestamp is, your demand for proof is pretty > > off the mark. If you still consider it to be a valid question, > > please rephrase it and clarify why exactly proof must be provided > > that people reading that timestamp (which is for vdb content only) > > will only be using that timestamp for vdb content. > >=20 > > Your request is akin to demanding proof that a hammer only be used as= =20 > > a hammer. It's a fricking hammer- it has one use, one way of being=20 > > used. If someone goes out of their way to be an idiot, they're an=20 > > idiot, not the specs problem. > >=20 > > Seriously, if you're actually worrying about some specific usage > > case, state it- on the face of it, your request for proof right now > > makes zero sense. Kindly provide a scenario or elucidation. >=20 > You're asking for a cache validation mechanism that's based not upon > what it logically invalidates, but upon something you assume to be > equivalent. Specifically, you assume that "VDB has changed" and "the > installed packages have changed" are exactly the same thing, and you're > wanting to build a cache based upon that highly questionable > assumption. There are at least two logically different sets of > 'changes' that might apply to VDB (metadata changes, and package > version changes), and you're attempting to confuse the two, along with > any others that people come up with later on. > > What's wrong with, instead, having cache files for "something has > changed", "the set of installed packages has potentially changed", "the > metadata for installed packages has potentially changed" and "the set of > installable packages has potentially changed"? That way you can write > your cache checks to depend explicitly upon the thing upon which they > depend (along with a global catch-all to make future new validation > mechanisms easier), not upon something you assume is equivalent but > probably isn't. Ah... there we go, you're again asking for specific timestamps such=20 that specific caches can be invalidated. Same as I said in the bug,=20 you want it, propose it. As you stated above, *still* a global=20 timestamp of some sort is needed. Seriously- if you want some specific cache timestamp, go nuts. The=20 global timestamp is still needed and that's the only one I give a damn=20 about at this juncture- I'm not as much interested in layering in new=20 hacky caches on the vdb to try and make it performant as I'm=20 interested in building flat out, a new vdb that is designed from the=20 ground up for efficiency/performance. When the old vdb format has the timestamp requirements, I can use that=20 to keep the two in sync (maintaining compatibility while being free=20 to start developing a better vdb, or alternate implementations- say=20 remote). Beyond that, for people less ambitious it serves as a=20 timestamp they can use for updating their own caches- not the most=20 fine grained admittedly, but it's also a rare scenario. Either way, you want specific cache timestamps, it's an addition to=20 this proposal- for example I'm specifically disinterested in adding a=20 pkg names cache because the gain from it isn't particularly high for=20 the scenarios I'm looking at (provides/use/iuse/depends/rdepends per=20 node being higher cost in my profilings). Admittedly it speeds up=20 simple lookups in the vdb of "what version do I have installed?", but=20 most folk do a pmerge/emerge -Dup for that (meaning full metadata=20 access still). ~harring --+JUInw4efm7IfTNU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksPiOcACgkQsiLx3HvNzgd9UQCg21E+Uv1CHCBd+Wc4mK2A0MiL pnMAoMo+JcARqRpel6/aIzTgeBPtcQJQ =gXFO -----END PGP SIGNATURE----- --+JUInw4efm7IfTNU--