[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hashsum mismatch prevention strategies



On Sun, May 20, 2012 at 06:30:06PM +0000, Raphael Geissert wrote:
> Goswin von Brederlow wrote:
> > Joerg Jaspert <joerg@debian.org> writes:
> > But I'm not convinced the number of files to download is actualy the
> > limiting factor:
> 
> It isn't, but it adds overhead.
> 
> > What is killing the pdiffs is the stop&go methodic the current
> > implementation has.
> 
> I'm not even sure a new field needs to be introduced. It's just a
> matter of stating that the fields are ordered and if you have hash X
> you need all the patches mentioned in that line and the ones that follow.

Assuming that would break reprepro repositories.

> 
> Additionally, I'd like an alternative way to distribute the pdiffs to
> be considered: after n days (say 2), gunzip the patches worth of one day
> and tgzip them. This not only reduces the number of requests needed to
> download all the files, but it also provides better compression. Adding an
> Index file to the tarball would be enough for apt to know which ones to
> apply and which ones to ignore.

A tar in between would complicate the code on the client, and break
backwards compatibility.

> 
> > Option C)
> > =========
> > 
> > The "Mirrors are going to be out-of-sync. Deal with it." option.
> 
> Yes, but not by the means of another service. Sync issues also occur on 
> private mirrors.
> 
> 
> What I had proposed on irc was a combination of a) and b), sort of:
> 
> Let's call it option D:
> 
> * Only the InRelease files have a constant name
> * All the other files have a date or some other sort of serial number 
> appended, e.g. Packages-12042014
> * Compatibility symlinks are kept in place, but it is known they will
> be prone to race conditions (404s, even).
> * APT and others find the names of the latest available indexes from
> the InRelease file
> * InRelease becomes the one and only place at which a mirror "switches"
> from one push to another.
> 

Which is basically the same I proposed as well [and what is option
C from the Ubuntu discussion].


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


Reply to: