Re: Less dinstall FTW?

[Helmut Grohne <helmut@subdivi.de>]

Thanks for your explanations!

On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote:
> As this suite is much smaller than the full archive, updating it can be
> done with much less overhead and is done with every cron.unchecked
> run. Packages.gz (amd64) is just 98 kb, Sources.gz is 180 kb compared to
> 8.5 MB each for the main archive. There are also no Contents indices.

One aspect I couldn't find in the discussion so far is reduction of
bandwidth on *my* end. Let us for a moment consider a user to run sid
with incoming enabled and the dinstall frequency cut in half. Are the
following conclusions correct?

 * The user would not receive packages any later than in the old setup
   (assuming a recent apt-get update).
 * If PDiffs are disabled, the user would be wasting less bandwidth for
   package lists, because the big package lists are now downloaded with
   half the frequency and the other lists are small. So less bandwidth
   is used here.
 * If PDiffs are enabled, I assume that incoming would not support
   PDiffs for its rapid rate of change. With PDiffs the number of diffs
   is interesting, because processing them usually is the limiting
   factor here. The number of PDiffs would be halved as well here, so
   the update would usually go faster.

For both download variants the effect is multiplied when using foreign
architectures.

Who hasn't disabled PDiffs, because they take way too long when the
network is fast?

>From this very limited POV the proposal appears to be an improvement.

Helmut