* David Kalnischkies <kalnischk...@gmail.com> [120210 02:44]:
> >> off-topic but often pdiffs don't really speed up apt-get update. Added
> >> roundtrip time latency on pulling several small files slows down the
> >> download unless you run update nightly.
> >
> > One of the reasons of this I think, is that the current pdiff
> > implementation in apt is really not optimal, see #372712.
>
> The real slowdown is that APT currently works on one pdiffs at the time.
> The solution for this is two-fold: First get all pdiffs needed - for debian
> this is easy as its strictly sequential, but other archives can (and some
> even do) use different paths so we need a bit more metadata to support these,
> too. After we have all these pdiffs we can merge these to one "big" pdiff and
> apply this one. As we walk over > 25 MB files only once and not for each
> patch we should be quiet a bit faster. The theory and even python code for
> the merge part can be found at [0], it's just that the APT team is since years
> so overcrowded that we haven't yet decided who can pick this one [/irony].
>
> If someone wants to work on that, feel free to drop a line to deity@l.d.o
> (and to Anthony) and i will try to help if time permits.
>
> [0] http://lists.debian.org/deity/2009/08/msg00169.html
In the reprepro package there is a program called rredtool that can also
merge .pdiff files. But I really suggest to merge them server-side.
Current apt works quite well with a Packages.diff that only needs one
diff to get to the current version, which speeds up everything and avoids
unnecessary traffic.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120210094246.ga...@client.brlink.eu
