On Wed, 14 Mar 2007, Fabian Keil wrote:

Wojciech Puchar <[EMAIL PROTECTED]> wrote:

        Regarding most (or many) of the port changes--say, upgrading
        foo-2.1.9_5 to foo-2.1.9_6, if  the upgrade could be done by
        downloading a binary diff file, could the resulting
        /usr/local/bin/foo-2.1.9_6 be achieved by downloading a
        relatively small binary patch?  Seems to me that smaller scale
        upgrades could be done this way in preference to re-compiling
        ports or downloading entire pacakes.  --Same would go for any

        Why is this a bad idea!

because if you change say 5 lines in program source of  1MB binary
program, resulting new 1MB binary will be MUCH different
byte-by-byte mostly because of address shifting so lots of pointers to
code (or data, rodata)  will change. so diff will be big.

Is that a guess or did you actually test and verify this?


Well, this can be done by diffing two different copies of a similar binary. 
Frankly, binary patches should be done thought IMHO because like Wojciech 
mentioned the differences would be huge.

Besides, the patches aren't portable, so the program would have to be 
recompiled in the target arch, diffed, then put to a patch file. This as a 
hunch / gut feeling I have, but the majority of the patches produced using this 
method would soon approach the original packages size (assuming that there were 
changes over the entire package and not a portion of it).

If you're thinking of creating a hotfix system though, that would be a good 
idea (assuming everything's dynamically linked as opposed to statically 
linked). When M$ moved their patch release infrastructure to their current 
smaller one, update sizes did decrease by a fairly large amount (2-3+ times?). 
The only thing is that keeping track of versions becomes an important thing and 
making sure that you have all the successive patches in a line becomes a 
mess--hence, you have to go to the Windows update site multiple times to update 
one Windows component, like .NET 1.1 for instance.

Just a few thoughts on the topic.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to