1 |
On Tue, Jun 01, 2010 at 04:53:31PM -0700, Zac Medico wrote: |
2 |
> On 06/01/2010 02:52 PM, Brian Harring wrote: |
3 |
> > That bug isn't about a collision, it's about files being replaced underneath |
4 |
> > Packages feet. Even with the tricks you've leveled the issue of things |
5 |
> > changing under foot still is possible- you've just made the race less |
6 |
> > likely. |
7 |
> |
8 |
> AFAIK the race is completely eliminated by the RCU-like snapshot |
9 |
> mechanism. I think I like your hash-in-the-filename idea better |
10 |
> though, since it seems simpler to implement and maintain. |
11 |
|
12 |
You're forgetting about how one actually updates the snapshot- client |
13 |
grabs the packages cache, starts pulling binpkgs. During that time |
14 |
the snapshot is being updated- the client now has a stale view of the |
15 |
repo, and since the repo's structure is based on cpv (which doesn't |
16 |
change regardless of metadata changing like use configuration) they |
17 |
can grab a binpkg that has the wrong metadata/checksums. |
18 |
|
19 |
It's racey in exactly the same was as before, the only difference is |
20 |
you switched it to rewrite the tbz2 in a temp file instead of directly |
21 |
to the tbz2. Reduction, but same level of risk for any form of |
22 |
updates. |
23 |
|
24 |
Snapshot script just duck tapes around the issue, while leaving the |
25 |
core flaw intact. |
26 |
|
27 |
> > What I was talking about was solving this issue once and for all via |
28 |
> > restructuring, and specifically refering to the potential of an md5 |
29 |
> > collision in the URI space- specifically what I'm implementing for pkgcore |
30 |
> > is the ability to do stupid stuff like this- |
31 |
> > |
32 |
> > http://host/binpkg-store/$MD5.{txz,tbz2,tgz} |
33 |
> |
34 |
> That would be the MD5 of the entire file, after compression and |
35 |
> having the xpak segment appended, right? |
36 |
|
37 |
Yep. The only potential issue here is the unlikely case of a CHF |
38 |
collision. There is a way to resolve that one too, although it is |
39 |
outside of what I'm willing to do format wise (namely a secondary url |
40 |
fallback). |
41 |
|
42 |
|
43 |
|
44 |
> > then have multiple views accessible just via pointing the binpkg repo remote |
45 |
> > url at |
46 |
> > |
47 |
> > http://host/views/license/oss-approved/ |
48 |
> > http://host/views/keywords/amd64/stable/ |
49 |
> > http://host/views/raw/ # no filtering on the view of the binpkg repo, see |
50 |
> > everything. |
51 |
> |
52 |
> So, the default path of a package would come from looking at the MD5 |
53 |
> in the Packages file and then mapping that to a path? |
54 |
|
55 |
default path would be defined in the preamble by a string interpolated |
56 |
pattern; whatever folk wanted to use. |
57 |
|
58 |
A sane default is %(host)s/raw-pkgs/%(md5)s.%(compressor_ext)s imo. |
59 |
|
60 |
|
61 |
> > Via restructuring where the binpkgs are stored and doing this approach, |
62 |
> > multiple views can be had easily into the repo. An additional benefit of |
63 |
> > this approach is that via making URI able to point outside the host, you |
64 |
> > could combine multiple seperate repositories into one just via a view. |
65 |
> |
66 |
> This might also be useful for creating per-profile views while |
67 |
> allowing packages to be shared between profiles in cases when |
68 |
> hosting a separate build would be redundant. It might be possible to |
69 |
> save lots of build time, disk space, and testing that way. |
70 |
> |
71 |
> Being able to have multiple builds of the same package with |
72 |
> different USE settings is also solves bug 150031 [1]. |
73 |
|
74 |
Yep and Yep. |
75 |
|
76 |
> >> Eventually, I'd like to see gentoo |
77 |
> >> officially distributing binary packages, so that we'll be able to |
78 |
> >> get a slice of the binary distribution pie. When that happens, we're |
79 |
> >> certainly not going to want to have race conditions like these in |
80 |
> >> our public binhosts. |
81 |
> >> |
82 |
> > |
83 |
> > I'd suggest abandoning the current repository layout of Packages then, since |
84 |
> > it's irrevocably flawed. You can hack around it via jamming timestamp/md5 |
85 |
> > info into URI, but that's not a sane solution. |
86 |
> |
87 |
> Shrug, it's a handy way to solve race conditions given the existing |
88 |
> version 0 format. It's not optimal, so we'll surely want something |
89 |
> better in version 1. |
90 |
|
91 |
The problem here is that version0 still maps down to the existing |
92 |
binpkg on disk layout. That layout is the core flaw here- as long as |
93 |
binpkgs are stored cpv orientated, version0 isn't able to do the crazy |
94 |
things I'm intending. |
95 |
~harring |