[Pierre Habouzit] > > As far as mirror bandwidth goes (including end user bandwidth *from* > > the mirrors), that's a problem for rsync/zsync to solve. > > 1- binary backages do not have the same name (so rsync/apt-get are lost) It's still a problem for rsync/zsync to solve. I didn't mean to say they had already solved it. zsync already seems to be moving in the direction of application-specific hacks - I don't see why "call an external script to produce a list of files to check the checksums against" should not be one such hack. Since zsync (unlike rsync) does all the heavy lifting on the receiving side, this seems very feasible. > 2- if you build them for real, they won't be exactly the same (think > of /usr/share/doc/your-package/changelog.Debian.gz e.g.) zsync already reaches inside a gzip file and effectively rsyncs the uncompressed version. No reason it couldn't be made a bit smarter so as to look inside the components of a .deb ar file. This being a fairly interesting use case for zsync, I expect it's already being considered, if not implemented. Peter
Attachment:
signature.asc
Description: Digital signature