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

Re: Hashsum mismatch prevention strategies



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.

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.

>> - One rsync run ought to be enough to mirror all of Debian (or any
>> derivate using similar structure). Not X, with various
>> include/excludes.
> 
> Doing a complete rsync run with --delay-updates shouldn't be to bad.

At the moment there are just too many files with a constant name for
that to be useful.


> 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.


Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


Reply to: