So, we're up to 180MB in updates.

[Alan McKinnon]

On Sat, 2006-07-15 at 11:51 -0400, Kent Borg wrote:

> [Warning, some philosophy here...]
> 
> Think about it.  In all that, how many actual bits fundamentally
> changed?  Let's imagine a lot of programming happened on some package
> (something that really isn't supposed to occur in released Dapper),
> how many could that be?  Maybe some graphics changed.  Still, it seems
> to me that the download has got to be well over 100-to-1 its inherent
> size.

That would be about right 

> I understand that a one-bit security fix can cause a recompile of,
> say, Openoffice.  And the result of doing a gigantic download because
> of one bit changing is terribly crude.  Think about it.  If we ran
> cities this way a single mis-installed oneway sign and we would have
> to rebuild NYC.  Or, maybe just rebuild Manhattan.  Or, maybe just
> rebuild one block of Manhattan.  Good thing in a real city we can
> usually just slap up the right sign.

The side effect problems of doing it any other way are horrific.

If the change is a text file, we could distribute a diff - that's easy
enough. Binaries are another story. To continue your analogy, this is
like issuing an instruction that all cities must remove the 14th sign
from the left at the 9th intersection on the 3rd highway, and replace it
with not one, but two new signs...

A possibility is to distribute only the binary files that changed, with
some thought it might be gotten to work, but I'd still be nervous about
the impact that will have on a running system. And also consider the
effect on the digest that all package managers maintain - this will also
have to be updated, but in my experience package managers are not built
to accommodate partial changes to the things they install.

alan