On 15634 March 1977, Niels Thykier wrote:
I am considering to look at this feature - I am looking for a review before I invest a lot of time on an implementation in case the design is going to be rejected.
Yay.
# Proposal I have spoken with Julian about the APT side and we would end up doing completely merged pdiffs for this to work (i.e. every patch must move you from the current state to the newest state). This means that every dinstall will lead to a new generation of all existing patches.
Ok.
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.
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?
@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. -- bye, Joerg
