1 |
On Thu, Nov 26, 2009 at 04:46:49PM +0000, Ciaran McCreesh wrote: |
2 |
> On Thu, 26 Nov 2009 08:33:03 -0800 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > > "Provide proof that all existing and future caches that would rely |
5 |
> > > upon this validation mechanism are functions purely and exclusively |
6 |
> > > dependent upon the VDB content, and I shall be happy to make the |
7 |
> > > change." |
8 |
> > The timestamp updating is for whenever the vdb content (addition of a |
9 |
> > pkg, pkgmoves being applied, removal of a pkg, modification of |
10 |
> > metadata, etc) is changed. That's all that timestamp is for. Vdb |
11 |
> > content. |
12 |
> > |
13 |
> > In light of what the timestamp is, your demand for proof is pretty |
14 |
> > off the mark. If you still consider it to be a valid question, |
15 |
> > please rephrase it and clarify why exactly proof must be provided |
16 |
> > that people reading that timestamp (which is for vdb content only) |
17 |
> > will only be using that timestamp for vdb content. |
18 |
> > |
19 |
> > 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 |
21 |
> > used. If someone goes out of their way to be an idiot, they're an |
22 |
> > idiot, not the specs problem. |
23 |
> > |
24 |
> > Seriously, if you're actually worrying about some specific usage |
25 |
> > case, state it- on the face of it, your request for proof right now |
26 |
> > makes zero sense. Kindly provide a scenario or elucidation. |
27 |
> |
28 |
> You're asking for a cache validation mechanism that's based not upon |
29 |
> what it logically invalidates, but upon something you assume to be |
30 |
> equivalent. Specifically, you assume that "VDB has changed" and "the |
31 |
> installed packages have changed" are exactly the same thing, and you're |
32 |
> wanting to build a cache based upon that highly questionable |
33 |
> assumption. There are at least two logically different sets of |
34 |
> 'changes' that might apply to VDB (metadata changes, and package |
35 |
> version changes), and you're attempting to confuse the two, along with |
36 |
> any others that people come up with later on. |
37 |
> |
38 |
> What's wrong with, instead, having cache files for "something has |
39 |
> changed", "the set of installed packages has potentially changed", "the |
40 |
> metadata for installed packages has potentially changed" and "the set of |
41 |
> installable packages has potentially changed"? That way you can write |
42 |
> your cache checks to depend explicitly upon the thing upon which they |
43 |
> depend (along with a global catch-all to make future new validation |
44 |
> mechanisms easier), not upon something you assume is equivalent but |
45 |
> probably isn't. |
46 |
|
47 |
Ah... there we go, you're again asking for specific timestamps such |
48 |
that specific caches can be invalidated. Same as I said in the bug, |
49 |
you want it, propose it. As you stated above, *still* a global |
50 |
timestamp of some sort is needed. |
51 |
|
52 |
Seriously- if you want some specific cache timestamp, go nuts. The |
53 |
global timestamp is still needed and that's the only one I give a damn |
54 |
about at this juncture- I'm not as much interested in layering in new |
55 |
hacky caches on the vdb to try and make it performant as I'm |
56 |
interested in building flat out, a new vdb that is designed from the |
57 |
ground up for efficiency/performance. |
58 |
|
59 |
When the old vdb format has the timestamp requirements, I can use that |
60 |
to keep the two in sync (maintaining compatibility while being free |
61 |
to start developing a better vdb, or alternate implementations- say |
62 |
remote). Beyond that, for people less ambitious it serves as a |
63 |
timestamp they can use for updating their own caches- not the most |
64 |
fine grained admittedly, but it's also a rare scenario. |
65 |
|
66 |
Either way, you want specific cache timestamps, it's an addition to |
67 |
this proposal- for example I'm specifically disinterested in adding a |
68 |
pkg names cache because the gain from it isn't particularly high for |
69 |
the scenarios I'm looking at (provides/use/iuse/depends/rdepends per |
70 |
node being higher cost in my profilings). Admittedly it speeds up |
71 |
simple lookups in the vdb of "what version do I have installed?", but |
72 |
most folk do a pmerge/emerge -Dup for that (meaning full metadata |
73 |
access still). |
74 |
|
75 |
~harring |