On Wed, 2009-02-18 at 17:18 -0800, Robin H. Johnson wrote:
> On Wed, Feb 18, 2009 at 11:27:41PM +0100, Robert Buchholz wrote:
> > On Wednesday 18 February 2009, Robin H. Johnson wrote:
> > > Using the converse, all files covered by AUX, DIST, MISC have GIT
> > > SHA1 commit ids. Explicitly performing a checksum on them is not
> > > needed, just extract it from Git.
> > These hashes would need to be regenerated for the rsync though, because 
> > otherwise it does not provide integrity and this would make tree 
> > signing impossible. Overlays would have to abandon the hashes though, 
> > otherwise you'll get the same merge trouble again.
> On the git->rsync gateway:
> For non-distfiles:
> 1. Extract SHA1 from Git 
> 2. Compare to actual file (Git does this implicitly, esp if you have
>    signed Git commits, but you can check again if you want).
> 3. Generate SHA256/RMD160/other.
> 4. Append the full hash to Manifest.

So how would this work for the developers themselves?

Do we use a separate Manifest.dist which would be used to generate the
server Manifest (and could be used locally to)? This would be one extra,
barely-used disk block per package leading to a >50 MB blow-up in the
sync tree size (more for the git tree, but that, I presume, is not a
problem).

This would mean that local manifests would need to be regenerated after
every sync. I supposed it should not be too hard to find all files
affected by the git pull/emerge --sync, and then regenerate only those.

Or have I misunderstood the proposal?

-- Arun