On Mon, Jan 20, 2014 at 07:21:56PM +0000, Anthony Towns wrote: > On Fri, Jan 17, 2014 at 04:13:34PM +0100, David Kalnischkies wrote: > > On Sat, Jan 04, 2014 at 07:34:07PM +0100, David Kalnischkies wrote: > > > So, I guess merging both could cross a lot of points of your list and > > > be relatively easily feed into unstable for proper field-testing. > > > (a upload of my part was planed as a christmas present to experimental, > > > but as usual: If you want to make deity laugh, tell her your plans) > > I just did this merging the other day and Michael pushed it to experimental > > (again), so everyone should feel free to give it a spin, you might be in > > for a pleasant surprise ??? depending on how much you trusted the > > "benchmark" in my previous mail. > > [technical, it was indeed as easy as using my POC and Anthonys rred and > > put some minor glue between them ??? very nice :D ] > > Very nice indeed. > > There's an extra patch at > > https://github.com/ajtowns/apt/commits/better-pdiffs-dk > > that makes a couple of minor cleanups in rred.cc. I think there's a few Thanks! Cleaning up is always good. :) You could also switch to the FileFd class we have in apt, as the name suggests its using Fds directly through, not FILE*, but it does e.g. this write continuation by itself. > more to do, but I got confused as to how the pkgAcqIndexMergeDiffs stuff > works, and will need to print that out to grok it, I expect... It is indeed a bit crazy (just as the name implies also here). Theory is that all pdiffs are downloaded in parallel, but all pdiffs know which are his siblings and the last of those siblings who is done with the download will go the extra mile of calling rred, which will pick up all siblings again based on the fact that they have a similar name (you had an explicit message, but this requires abi changes to do it). In practice the last one in line will also be the last one to finish downloading, but such an assumption could get messed up by redirects, so it felt safer this way (and is needed to handle fallback in error cases anyway). > > Breakage potential: > > I decided for now to enable client-side merge by default but with > > detection for the X-Patch-Precedence field reprepro has introduced?? if it > > has merged patches on the server side, which falls back to the old > > handling. > > Ah, nice, that seems like it should make it backwards compatible in > practice. > > It looks to me like dak and reprepro are the only tools that generate > pdiffs currently, fwiw. Those are the only ones I know of as well, so I have good hope that this pdiff change can indeed be activated without complains in practice, *spoiler alert* just like "xztreme" changes in dists/ (thanks btw). ;) Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature