| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Tiziano Müller wrote: |
| 5 |
> Am Sonntag, den 08.02.2009, 12:36 -0800 schrieb Zac Medico: |
| 6 |
>> -----BEGIN PGP SIGNED MESSAGE----- |
| 7 |
>> Hash: SHA1 |
| 8 |
>> |
| 9 |
>> Tiziano Müller wrote: |
| 10 |
>>> But if your target is to reduce the size of the metadata cache, why |
| 11 |
>>> store the hashes of the eclasses in the ebuild's metadata and not in a |
| 12 |
>>> seperate dir? They have to be the same for every ebuild, don't they? |
| 13 |
>>> In case you have an average number of eclasses which is bigger than 4, |
| 14 |
>>> you can even store the full hash with less space used than with |
| 15 |
>>> truncated hashes for all eclasses. |
| 16 |
>> The problem with having eclass integrity data shared in a separate |
| 17 |
>> file is that it creates a requirement for all cache entries which |
| 18 |
>> reference the same eclasses to be consistent with one another. This |
| 19 |
>> means that a single cache entry can no longer be updated atomically. |
| 20 |
>> For example, before updating the shared eclass integrity data, you'd |
| 21 |
>> want to make sure that you first discard all of the cache entries |
| 22 |
>> which reference it. Although it can be done this way, I think it's |
| 23 |
>> much more convenient to have all of the integrity data encapsulated |
| 24 |
>> within each individual cache entry. |
| 25 |
> Ok, let me see if I get this: Since parts of the content of a |
| 26 |
> metadata-entry (like the DEPEND/RDEPEND vars) depend on the contents of |
| 27 |
> the eclass used by the time a cache entry got generated, you want to |
| 28 |
> store the eclass' hash in the ebuild entry to make sure the entry gets |
| 29 |
> invalidated once the eclass changes. Is that correct? |
| 30 |
|
| 31 |
Right. By having each cache entry encapsulate it's own integrity |
| 32 |
data, the program updating the cache is never required to update |
| 33 |
more than one file at a time. Having shared integrity data would |
| 34 |
imply that the program would have the burden of maintaining |
| 35 |
consistency across all cache entries. |
| 36 |
- -- |
| 37 |
Thanks, |
| 38 |
Zac |
| 39 |
-----BEGIN PGP SIGNATURE----- |
| 40 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 41 |
|
| 42 |
iEYEARECAAYFAkmPWTEACgkQ/ejvha5XGaOLHQCg0wGuRIkPCmQUQ2k14RjQlpv0 |
| 43 |
C54AoNqBaA6d3xyO6FuNz1GO7ZJ7y7E6 |
| 44 |
=D/ei |
| 45 |
-----END PGP SIGNATURE----- |
Archives