On Thu, Nov 26, 2009 at 04:46:49PM +0000, Ciaran McCreesh wrote:
> On Thu, 26 Nov 2009 08:33:03 -0800
> Brian Harring <ferringb@...> 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
> > pkg, pkgmoves being applied, removal of a pkg, modification of
> > metadata, etc) is changed. That's all that timestamp is for. Vdb
> > content.
> > 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.
> > Your request is akin to demanding proof that a hammer only be used as
> > a hammer. It's a fricking hammer- it has one use, one way of being
> > used. If someone goes out of their way to be an idiot, they're an
> > idiot, not the specs problem.
> > 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.
> 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
that specific caches can be invalidated. Same as I said in the bug,
you want it, propose it. As you stated above, *still* a global
timestamp of some sort is needed.
Seriously- if you want some specific cache timestamp, go nuts. The
global timestamp is still needed and that's the only one I give a damn
about at this juncture- I'm not as much interested in layering in new
hacky caches on the vdb to try and make it performant as I'm
interested in building flat out, a new vdb that is designed from the
ground up for efficiency/performance.
When the old vdb format has the timestamp requirements, I can use that
to keep the two in sync (maintaining compatibility while being free
to start developing a better vdb, or alternate implementations- say
remote). Beyond that, for people less ambitious it serves as a
timestamp they can use for updating their own caches- not the most
fine grained admittedly, but it's also a rare scenario.
Either way, you want specific cache timestamps, it's an addition to
this proposal- for example I'm specifically disinterested in adding a
pkg names cache because the gain from it isn't particularly high for
the scenarios I'm looking at (provides/use/iuse/depends/rdepends per
node being higher cost in my profilings). Admittedly it speeds up
simple lookups in the vdb of "what version do I have installed?", but
most folk do a pmerge/emerge -Dup for that (meaning full metadata