[CentOS-devel] deltarpm and presto for centos

Jeff Johnson n3npq at mac.com
Sun Nov 15 19:59:33 UTC 2009


On Nov 15, 2009, at 2:45 PM, Jonathan Dieter wrote:

> On Sun, 2009-11-15 at 13:44 -0500, Jeff Johnson wrote:
>> FWIW, there are deep fundamental design issues wrto Courgette
>> that have nothing to do with with whether Google is choosing Courgette
>> for Chromium peculier updates.
>> 
>> For starters:
>> 
>> 1) RFC 3229 at http://www.rfc-editor.org/rfc/rfc3229.txt
>> 
>> 	This is what subversion uses (afaik) instead of xdelta
>> 	While I privately like xdelta _A LOT_ and I think
>> 	that Josh McDonald's master's thesis, and xdelta[123] are
>> 	the cat's pajama's, xdelta code is quite obscure and
>> 	hard to justify deploying generally. YMMV, everyone's does, but
>> 	(objectively) subevrsion chose vdelta rather than xdelta
>> 	because xdelta code is insanely difficult and uncommented,
>> 	and uses vdelta (ala RFC 3229) instead.
> 
> FWIW, I think the delta algorithm is one of the smaller problems
> deltarpm needs to deal with right now.
> 

But perhaps the current patent infringement actions underway wrto Courgette
_IS_ an issue, particularly for Fedorable (and other risk-averse FLOSS distros):

	http://www.h-online.com/open/news/item/Patent-action-over-Google-s-Courgette-845028.html

But you seem not to be able to find any code relevant to implementing
Courgette in presto (per yr bugzilla entries), so it likely
Simply Doesn't Matter.


>> 2) disassembling code to remove pointer entropy (as in Courgette)
>> maye be a win for executables, but is not generally useful for presto
>> (or packaging).
> 
> To clarify for others following this thread, most of the files in an rpm
> are data, *not* executables.
> 
> Deltarpm currently has two big problems that keep it from having hugely
> efficient deltas even when two rpms have barely changed.
> 
> 1) Any colored binaries that aren't in a multilib directory
> (i.e. /usr/bin/*) are never delta'd at all.  This was because we didn't
> want to lose the complete delta because some 32-bit package on a 64-bit
> machine was missing some file in /usr/bin.  We may want to rethink this
> now as 64-bit installs tend to have fewer 32-bit packages then when this
> decision was made.
> 2) A small change in an uncompressed file will result in a huge change
> after it's been compressed.  Many of the larger packages have at least
> some compressed files and those files are essentially not delta'd at
> all.
> 

Heh, colored binaries not in a multilib directory, and doubly
compressed files, are the least of the problems with presto deltafication imho.

> In my mind, at least, solving these two problems will have a far bigger
> effect in reducing deltarpm size than adopting Courgette.
> 

Have fun!

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3370 bytes
Desc: not available
Url : http://lists.centos.org/pipermail/centos-devel/attachments/20091115/e5d6f1f3/attachment.bin 


More information about the CentOS-devel mailing list