Fedora extras metadata

[Thomas M Steenholdt]

Michael Schwendt wrote:
>> /Thomas
> 
> What does the algorithm look like?
> 
> "Handshake" implies bidirectional communication, which is not
> available. We only have "slave retrieves from master" or "slave retrieves
> from slave" relationships. Mutual exclusion is not possible either. Flag
> files don't make the mirroring an atomic operation. The master can still
> break the scheme and push updates while a mirror is downloading in believe
> that the previously checked flag file was up-to-date.
> 

IIRC, something like echoing the output of `date` into af file named 
"mirror.wherever.com" in a special dir, upon successful synchronization 
from upstream mirror. That same file would be deleted when starting the 
next sync (there are tricks you can do, like download new packages to a 
temporary dir before deleting old packages and moving stuff in place, to 
shorten that period as much as possible). The point would be that if I'm 
syncing from mirror.somehost.com, I can check if the file 
mirror.somehost.com exists before even trying. If it exists, the mirror 
is consistent, but could still be stale. Staleness would be evident from 
the timestamp.

Also, since we would sync the special directory with the 
mirror.somehost.com file, we can even track problems to watever upstream 
  mirror host and check how old this particular set of packages has been 
on their way from the main site.

Something along those lines.

See http://www.debian.org/mirror/ftpmirror for more info on how the 
debian project does it, and perhaps we can be inspired by that. search 
for project/trace on that site, since that's where they'll throw the 
timestamp file.

/Thomas