kline at tao.thought.org
Wed Mar 14 23:35:11 UTC 2007
On Wed, Mar 14, 2007 at 12:29:58PM -0700, youshi10 at u.washington.edu wrote:
> On Wed, 14 Mar 2007, Fabian Keil wrote:
> >Wojciech Puchar <wojtek at tensor.gdynia.pl> 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?
> 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).
All valid points. How far the idea of patches goes would clearly
depend on how many type/flavors of patches there were and how
many version. I've crom things to update daily, so for me, the
max-diffs would be 2. Using "foo" above: if I had foo-2.1.9_5
and somehow missed _6 and _7, too bad; a rebuild or package download
would be needed. The main thing (as I understand the issue)
would be the size of the patch. A small reorg of binary can
mean a large patch... .
> 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.
Yep. I (may) know somebody at M$ who says that they've got
headaches that a million Exceedrin wouldn't help. A friend tried
to patch his recent XP to get the new daylight time. He gave up
after an hour of ping-ponging around.
> Just a few thoughts on the topic.
> freebsd-questions at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
Gary Kline kline at thought.org www.thought.org Public Service Unix
More information about the freebsd-questions