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