Fwd: Smart 1.4.1 Usage in Fedora 17

[Jeffrey Johnson]

Begin forwarded message:

> From: Jeffrey Johnson <n3npq at me.com>
> Subject: Re: Smart 1.4.1 Usage in Fedora 17
> Date: January 13, 2013 11:40:35 PM EST
> To: Mark Hatle <mark.hatle at windriver.com>
> Cc: smart at lists.labix.org
> 
> 
> On Jan 13, 2013, at 6:48 PM, Mark Hatle wrote:
> 
>> On 1/13/13 3:25 PM, Stephen Morris wrote:
>>> Hi,
>>>     Having moved from Mandriva 2011 to Fedora 17 as the closest distro
>>> I can find to Red Hat 6 which we are using at work, I am trying to use
>>> Smart 1.4.1. Ignoring a problem that I was getting under Mandriva that
>>> is also occurring randomly on Fedora as well, I am trying to get Smart
>>> to use the Yum functionality of using delta rpms where possible for
>>> updates. The impression I get at the moment is that when Smart downloads
>>> the rpms it is downloading full rpms rather than deltas, if that is not
>>> correct how do I get Smart to provide the same messages as Yum does in
>>> terms of downloading the deltas and informing the user that it is using
>>> the delta to rebuild the rpm? I am using Smart 1.4.1 downloaded from
>>> your site as Fedora 17 only provides Smart 1.3.1 in their repositories,
>>> and if I remember correctly Smart 1.3.1 doesn't provide support for
>>> mirror lists which I am using in conjunction with base urls.
>> 
>> As far as I know, Smart does not support deltarpms at this point.  I'd love it if someone has implemented it though...
>> 
> 
> Delatapms explode entire *.rpm packages in order to do delatfication
> with minimal entropy (and maximum bandwidth reduction from deltafication).
> 
> The cost of reconstructing a *.rpm from the bits-and-pieces (including recompression)
> is CPU intensive on the client.
> 
> There is also the combinatorial failure keeping track of all possible "upgrade" starting
> points.
> 
> Short answer:
> 	Delatrpms are the wrong implementation.
> 
> Instead: Use --rsyncable to generate *.rpm and then rsync across the wire for most
> of the gain without the client CPU cost (from recompressing), and the server side
> combinatorial explosion attempting to maintain all possible deltas for "upgrade".
> 
> Disclaimer:
> 	Yes I have a minority/contrarian opinion. And you won't be happy testing
> 	bandwidth reduction UNLESS both sides are --rsyncable (and @rpm.org using
> 	system zlib and/or xz payload compression is most definitely not --rsyncable).
> 
> hth
> 
> 73 de Jeff
> 
> 
>> --Mark
>> 
>>> regards,
>>> Steve
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20130113/5ee61200/attachment-0002.htm>