Joerg Jaspert: > On 15634 March 1977, Niels Thykier wrote: > [...] >> To avoid a combinational blow up, Julian and I propose that we limit the >> number patch generations to a low constant. This would limit the number >> of patches to a factor 3x of the current number. We can further reduce >> the number by reducing the number of pdiffs. > > We currently seem to do up to 56 of them. And (for today) seem to cover > a timeframe from last-run-on-17th-December to first run of todays, so > about two weeks of pdiffs. >
Ack, 14 days assuming 4 dinstalls per day. >> My understanding is that 3 generations will be sufficient to avoid >> issues by giving "apt(-get) update" at least 6 hour window to complete >> before there is an issue. >> As that pdiffs are only used during an "apt(-get) update", there is no >> reason to be concerned about stale metadata in the Index after apt(-get) >> has fetched all the files. > > Does 3 generations mean we will have cover for less than a day, or do i > misunderstand something here? > The generation represents a different "time axis" than the one you are thinking of. On one axis, we have "how many dinstalls can you be behind and still get patches?". This is the "only axis" we have right now and is currently set to 56 dinstalls (~14 days). For reference, the code refers to the this limit/time axis as "--maxdiffs"/"MaxDiffs". When we start to do patch merging, we introduce the time axis "which dinstall state will this patch forward you to?". I referred to this as "Generations" in my description in a lack of a better word (I am open to suggestions for a better name). As said, the primary purpose of using multiple generations is to avoid removing pdiffs referenced by an Index file while an "apt-get update" is fetching files (Time of fetch for Index vs. time of fetch for the actual pdiff file). As I understand it, we will ever need more than 3 generations, but that still implies that we will have 3*56 = 168 pdiff files. >> @FTP masters: Do you agree with the "fully-merged" approach with N >> generations (with N=3 by default) as a solution to this request? > > I'm happy with it, as long as we cover a long enough timeframe of diff > generation with it, ie. multiple days. > > And preferably if it works as a drop-in replacement and we can just > start using it whenever it gets merged. > Ok. :) I will try to have a look at it soonish. Thanks, ~Niels
