binary patches?

[Gary Kline]

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?
> >
> >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).


	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.

	gary


> 
> Just a few thoughts on the topic.
> -Garrett
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
  Gary Kline  kline at thought.org   www.thought.org  Public Service Unix