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
dependencies.
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?
Fabian
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.
-Garrett
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
