1 |
On Wed, 2009-02-18 at 17:18 -0800, Robin H. Johnson wrote: |
2 |
> On Wed, Feb 18, 2009 at 11:27:41PM +0100, Robert Buchholz wrote: |
3 |
> > On Wednesday 18 February 2009, Robin H. Johnson wrote: |
4 |
> > > Using the converse, all files covered by AUX, DIST, MISC have GIT |
5 |
> > > SHA1 commit ids. Explicitly performing a checksum on them is not |
6 |
> > > needed, just extract it from Git. |
7 |
> > These hashes would need to be regenerated for the rsync though, because |
8 |
> > otherwise it does not provide integrity and this would make tree |
9 |
> > signing impossible. Overlays would have to abandon the hashes though, |
10 |
> > otherwise you'll get the same merge trouble again. |
11 |
> On the git->rsync gateway: |
12 |
> For non-distfiles: |
13 |
> 1. Extract SHA1 from Git |
14 |
> 2. Compare to actual file (Git does this implicitly, esp if you have |
15 |
> signed Git commits, but you can check again if you want). |
16 |
> 3. Generate SHA256/RMD160/other. |
17 |
> 4. Append the full hash to Manifest. |
18 |
|
19 |
So how would this work for the developers themselves? |
20 |
|
21 |
Do we use a separate Manifest.dist which would be used to generate the |
22 |
server Manifest (and could be used locally to)? This would be one extra, |
23 |
barely-used disk block per package leading to a >50 MB blow-up in the |
24 |
sync tree size (more for the git tree, but that, I presume, is not a |
25 |
problem). |
26 |
|
27 |
This would mean that local manifests would need to be regenerated after |
28 |
every sync. I supposed it should not be too hard to find all files |
29 |
affected by the git pull/emerge --sync, and then regenerate only those. |
30 |
|
31 |
Or have I misunderstood the proposal? |
32 |
|
33 |
-- Arun |