Date: Wed, 14 Mar 2007 15:35:15 -0800 From: Gary Kline <kline@tao.thought.org> To: youshi10@u.washington.edu Cc: freebsd-questions@freebsd.org Subject: Re: binary patches? Message-ID: <20070314233515.GB96282@thought.org> In-Reply-To: <Pine.LNX.4.43.0703141229580.20708@hymn01.u.washington.edu> References: <20070314201221.3503c338@localhost> <Pine.LNX.4.43.0703141229580.20708@hymn01.u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 14, 2007 at 12:29:58PM -0700, youshi10@u.washington.edu wrote: > On Wed, 14 Mar 2007, Fabian Keil wrote: > > >Wojciech Puchar <wojtek@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Gary Kline kline@thought.org www.thought.org Public Service Unix
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314233515.GB96282>