Rawhide 20080328 Snapshot Released

[David Timms]

Jesse Keating wrote:
> On Sat, 2008-03-29 at 22:59 +0900, John Summerfield wrote:
>> Is it difficult to release jigdos?
> 
> The problem is this.
> 
> Jigdo would require the exploaded bits be available by http.  Trying to
> sync all that content around the mirrors in any sort of reasonable time
> frame is not going to happen.  Hanging the entire tree off of a single
> http point is not going to happen either, that point would quickly drown
> under the connections.  We can't just rely on rawhide as tomorrow the
> rawhide content will be different and you wouldn't be able to complete
> your jigdo.
> 
> If we're to have any sort of fast to the public snapshoting, we have to
> use a delivery mechanism that is capable of spreading the bandwidth load
> throughout the users without bringing down the host.  Right now, that
> only leaves us with bittorrent as an option.
> 
> Now, if there were some way to combine bittorrent and jigdo and if jigdo
> had better failover methods when mirrors are hit without the content we
> could potentially do something better.  Jigdo + rawhide + whatever you
> already have for the majority of the content, bittorrent to suck down
> the very last little bit or something along those lines.

One way to make bittorrent for the {iso} faster may be to:
- build iso as normal
- mount the iso
- build the torrent of the mounted iso
     now we have a torrent in little rpm {+ other bits} chunks.
- user gets set to download this torrent, but puts the download location 
in the same location that he had his previous copy of mounted iso.
   note: the practice of including a subfolder in the .torrent 
definition makes this difficult - because you need to mess with what the 
path inside the new torrent will be.

- force recheck function {azureus}
- each pre-downloaded {existing} file is checked against the torrent
- bt client only downloads the changed chunks / new files.

- need a tool to rebuild the identical iso out of the copy of the 
mounted tree...  including the iso structure and boot parts.

Further it would be cool if bt client could know about:
- fastest: bits I may already have on my local machine
- faster: bits I have on my local network
- fast: bits that my ISP is mirroring {and not charging me download for}
- medium: in country mirrors.
- bittorrent normal method.
and use them in that order.

If any of that actually makes sense, let me know if I can be of assistance.

DaveT.