Fwd: Smart 1.4.1 Usage in Fedora 17

[Stephen Morris]

On 01/14/2013 03:41 PM, Jeffrey Johnson wrote:
>
>
> Begin forwarded message:
>
>> *From: *Jeffrey Johnson <n3npq at me.com <mailto: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 
>> <mailto:mark.hatle at windriver.com>>
>> *Cc: *smart at lists.labix.org <mailto: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.
So far for me this is not an issue. I'm running an AMD FX 8350 4 GHz 8 
core cpu which seems to be able to handle everything I've done so far 
with minimal effort.
>>
>> There is also the combinatorial failure keeping track of all possible 
>> "upgrade" starting
>> points.
 From what I have seen so far there seems to be only 1 delta version 
kept for updates, and if the version that is installed doesn't match the 
version the delta is designed to update then yum downloads the full rpm 
as an update, either that or Fedora packages programs that need to be 
installed (maybe as a result of dependencies) in the updates repository 
rather than their base repository. But either way, given that I have a 
download limit on my plan, if I can't get the packages from my isp 
(because they are older than what is available via the mirror list) 
which are free, then I want to minimise as much as possible the 
bandwidth used to download the packages, so from my perspective deltas 
are ideal.

regards,
Steve

>>
>> 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/20130115/198f1052/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samorris.vcf
Type: text/x-vcard
Size: 130 bytes
Desc: not available
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20130115/198f1052/attachment-0003.vcf>