1 |
Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> Tiziano Müller wrote: |
6 |
> > Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico: |
7 |
> >> For the digest format, I suggest that we use the leftmost 10 |
8 |
> >> hexadecimal digits of the SHA-1 digest. The rationale for limiting |
9 |
> >> it to 10 digits (out of 40) is to save space. Due to the avalanche |
10 |
> >> effect [2], 10 digits should be sufficient to ensure that problems |
11 |
> >> resulting from hash collisions are extremely unlikely. |
12 |
> > I'd recommend to prefix the digest with a "{TYPE}" (like for hashed |
13 |
> > passwords) to be able to change the digest algorithm as needed |
14 |
> > (especially in regards to the current SHA successor competition). |
15 |
> > This allows a future package manager which might use SHA-3 for hashing |
16 |
> > (once it's released) to still check old digests. Furthermore it would |
17 |
> > allow for easier transition and only needs a definition of allowed |
18 |
> > hashes instead of a specific one. |
19 |
> |
20 |
> I like that idea. That way it's not necessary to bump the EAPI in |
21 |
> order to change the hash function. So, a typical DIGESTS value might |
22 |
> look like this: |
23 |
> |
24 |
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3 |
25 |
> |
26 |
> >> The primary reason to use a digest for cache validation instead of a |
27 |
> >> timestamp is that it allows the cache validation mechanism to work |
28 |
> >> even if the tree is distributed with a protocol that does not |
29 |
> >> preserve timestamps, such as git or subversion. This would make it |
30 |
> > Well, usually you don't keep intermediate or generated files in a VCS, |
31 |
> > so why the metadata? |
32 |
> |
33 |
> People who distribute overlays commonly ask if it's possible to |
34 |
> distribute metadata cache with the overlay. Using a format that |
35 |
> doesn't rely on timestamps will allow them to distribute metadata |
36 |
> cache using their existing infrastructure, which is typically git or |
37 |
> subversion. In addition to overlays, it would also be useful for |
38 |
> forks of the entire gentoo tree, such as the funtoo tree [1]. |
39 |
> |
40 |
> [1] http://github.com/funtoo/portage/tree/master |
41 |
|
42 |
Ok, after having the technical details discussed, I'd like to know which |
43 |
overlays or trees could really make use of it. |
44 |
Because small overlays surely won't generate the metadata because it is |
45 |
cumbersome to generate the metadata and isn't really a speed issue. |
46 |
Most larger overlays/repositories will probably be able to setup rsync |
47 |
or implement a procedure using cron+tarball. |
48 |
So, who exactly is asking about being able to distribute the metadata |
49 |
cache via a VCS? |
50 |
|
51 |
|
52 |
-- |
53 |
------------------------------------------------------- |
54 |
Tiziano Müller |
55 |
Gentoo Linux Developer, Council Member |
56 |
Areas of responsibility: |
57 |
Samba, PostgreSQL, CPP, Python, sysadmin |
58 |
E-Mail : dev-zero@g.o |
59 |
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 |