1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Brian Harring wrote: |
5 |
> On Mon, Feb 09, 2009 at 11:55:41AM -0800, Zac Medico wrote: |
6 |
>> All that I can say right now is that I recall questions about it in |
7 |
>> the past from overlay maintainers (I don't have a list) and the |
8 |
>> funtoo project is the only one which I can name offhand. |
9 |
>> |
10 |
>> However, the ability to distribute cache via a vcs is only an |
11 |
>> ancillary feature which is made possible by the DIGESTS data. The |
12 |
>> DIGESTS data is useful regardless of the protocol that is used to |
13 |
>> distribute the cache, since it allows the cache to be properly |
14 |
>> validated for integrity. So, the real primary reason for introducing |
15 |
>> the DIGESTS data is to provide a proper solution for cases like bug |
16 |
>> #139134 [1] in which invalid metadata cache goes undetected. |
17 |
> |
18 |
> I'm sorry, but this proposal smells something awful. Because of the |
19 |
> mtime requirement on cache entries you're proposing jamming another |
20 |
> 1.4MB into the cache for validation purposes (which should be 4x that |
21 |
> since a full checksum really should be in there) while trying to |
22 |
> maintain compatibility. |
23 |
|
24 |
As I've said before [1], 10 hex digits gives 1.1e12 possible |
25 |
combinations and that's probably sufficient for the given application. |
26 |
|
27 |
> Frankly, forget compatibility- the current format could stand to die. |
28 |
> The repository format is an ever growing mess- leave it as is and |
29 |
> work on cutting over to something sane. |
30 |
|
31 |
Changing the repository layout is a pretty radical thing to do. |
32 |
You're welcome to start a new subject for that if you'd like but I'd |
33 |
prefer to keep the scope of this thread focussed on the cache format |
34 |
for the existing repository layout. |
35 |
|
36 |
> Overlay maintainers who want the latest/greatest obviously can convert |
37 |
> over also; one would hope their would be enough cleanup to make it |
38 |
> worth their time. |
39 |
> |
40 |
> As for the nasty gentoo-x86 compatibility, basically, do the |
41 |
> following: |
42 |
> |
43 |
> 1) maintain the existing cvs repo as is |
44 |
> 2) iron out what cleanup/restructuring is desired. glep55 being |
45 |
> jammed in here is a potential for example. Nail down the new repo |
46 |
> format basically (with an eye for translating the cvs repo to it on |
47 |
> the fly). |
48 |
> 3) use an eclass index holding the checksums, w/ the cache entries |
49 |
> referencing the index numbers rather (sorting the index by |
50 |
> consumption, meaning the more ebuilds using it the lower the index): |
51 |
> this brings the cache addition down to around 285KB (acceptable imo) |
52 |
> while giving full flexibility in the checksums available for eclasses. |
53 |
> This is assuming the current flat_list format is still in use in the |
54 |
> new repo... |
55 |
|
56 |
As previously discussed [2], having shared integrity data (as you |
57 |
suggest) has implications in terms of reduced simplicity and robustness. |
58 |
|
59 |
My intention is for the cache format to be both simple and robust. |
60 |
It may require some extra space in order to achieve these goals, but |
61 |
I think it's well worth it. When accessing a given cache entry, it's |
62 |
very important that the package manager be able to reliably validate |
63 |
it's integrity (given that the package manager has no control over |
64 |
the implementation details of the cache generation infrastructure), |
65 |
and I believe that the proposed DIGESTS data will solve this problem |
66 |
in a simple and robust manner. |
67 |
|
68 |
[1] |
69 |
http://archives.gentoo.org/gentoo-dev/msg_d92eddd796dcc7b9272cc8b8a5a9ca18.xml |
70 |
[2] |
71 |
http://archives.gentoo.org/gentoo-dev/msg_94a65c9f395706a112ec903b611aad0e.xml |
72 |
- -- |
73 |
Thanks, |
74 |
Zac |
75 |
-----BEGIN PGP SIGNATURE----- |
76 |
Version: GnuPG v2.0.9 (GNU/Linux) |
77 |
|
78 |
iEYEARECAAYFAkmR6dYACgkQ/ejvha5XGaNlkwCeLA+roi+zg392R4HsWIuXIGrK |
79 |
nw4AoNztwEEioDDqPkVTv3pFKRrYUXKv |
80 |
=TRW8 |
81 |
-----END PGP SIGNATURE----- |