1 |
On Tue, Jan 12, 2010 at 10:12:52AM +0000, Ciaran McCreesh wrote: |
2 |
> On Mon, 11 Jan 2010 15:35:51 -0700 |
3 |
> Denis Dupeyron <calchan@g.o> wrote: |
4 |
> > I'm a bit surprised by the low amount of discussions this topic has |
5 |
> > generated. |
6 |
> |
7 |
> There's no discussion because Brian refuses to address any comments on |
8 |
> the proposal and just says "we should do it anyway, and if you want it |
9 |
> done properly instead, do it yourself". |
10 |
|
11 |
This is a bit of bullshit, per the norm. There is plenty of |
12 |
discussion- the problem is you don't like the direction it's gone. |
13 |
You want a whole new vdb- I don't oppose that. However I'm not |
14 |
interested in trying to standardize a new vdb format into PMS, at |
15 |
least not yet. |
16 |
|
17 |
Your argument can basically be summed up as "don't do the minimal |
18 |
tweak, do the whole new vdb with defined caches that all can share". |
19 |
|
20 |
Which is a fine notion, but not at all what I'm interested in- I want |
21 |
smething w/in the next 6 months PMs can start deploying for user |
22 |
benefit. I've literally seen discussions about vdb2 for >5 years now- |
23 |
pinning performance bets on a white elephant is not in my interest. |
24 |
Further, a vdb2 specified only in spce is useless w/out actual long |
25 |
term usage of it for performance/reliability testing. |
26 |
|
27 |
|
28 |
The daft thing about this is that you're ignoring one core transition |
29 |
issue w/ vdb2- if someone did create a vdb2, they still would need a |
30 |
synchronization mechanism (one quite similar to what I'm proposing). |
31 |
Already stated that in the bug- |
32 |
|
33 |
http://bugs.gentoo.org/show_bug.cgi?id=290428#c11 |
34 |
|
35 |
Repeating the relevant snippet for your benefit, consider the |
36 |
following chain of events- |
37 |
|
38 |
1) portage/pkgcore support the PMS defined vdb2 while paludis doesn't |
39 |
2) portage/pkgcore are invoked modifying the livefs; vdb1, vdb2 is |
40 |
updated. |
41 |
3) paludis is invoked. vdb1 is updated, vdb2 is not |
42 |
4) portage and pkgcore now cannot rely upon vdb2, since vdb1 now |
43 |
contains extra modifications due to paludis not supporting vdb2. |
44 |
|
45 |
|
46 |
To address #4, you need a way to detect that vdb1 was modified... then |
47 |
portage/pkgcore can synch vdb2 up w/ the changes in vdb1 (namely via |
48 |
basically rebuilding vdb2 from vdb1). |
49 |
|
50 |
The only real alternative to the issue above is to that of dropping |
51 |
vdb1- when you jump to vdb2, you drop vdb1. This means all existing |
52 |
tools have to know of both locations, have to support at least read on |
53 |
both locations- if a PM (again, paludis for the example) didn't |
54 |
support VDB2, under the alternative approach paludis wouldn't be |
55 |
usable since there would not be a vdb for it to inspect. |
56 |
|
57 |
In my opinion that is not a viable alternative- but you're free to |
58 |
propose whatever the hell you want. |
59 |
|
60 |
|
61 |
Summarizing; the synchronization primitive is needed for any future |
62 |
vdb2; once all vdb modifiers (paludis being the sole hold out per the |
63 |
norm) support updating the timestamp (and a couple of months have |
64 |
gone by), you get the following benefits- |
65 |
|
66 |
1) PMs can rebuild their vdb cache validation to use that timestamp, |
67 |
simplifying their code and reducing redundancy in their validation |
68 |
2) caches that are currently too expensive to deploy due to the cost |
69 |
of having to validate their way through the vdb can rely on |
70 |
effectively a boolean- is the timestamp newer then what they know of. |
71 |
This makes said caches access far faster, making them a net win |
72 |
(instead of a net loss)- portages vdb metadata cache comes to mind for |
73 |
this one for example. |
74 |
3) interested parties can start developing their own vdb2, including |
75 |
letting users play with it while avoiding forced lock in (this is good |
76 |
on multiple accounts- a vdb2 existing only in a spec is worthless in |
77 |
performance promises compared to a vdb2 implemented and tested). |
78 |
|
79 |
|
80 |
Summing it up; what ciaran wants is reliant on what I'm proposing, |
81 |
what I'm proposing provides tangible benefits now, not years down the |
82 |
line as his proposal would entail. |
83 |
|
84 |
There's the lovely executive summary. |
85 |
~harring |