[Mageia-discuss] Suggestions for the ISO

Sat Nov 6 19:58:11 CET 2010

Olivier Thauvin a écrit :
+> * andre999 (andr55 at laposte.net) wrote:
+>    
+>>> * andre999 (andr55 at laposte.net) wrote:
+>>>
+>>>        
+>>>> Donald Stewart a écrit :
+>>>>
+>>>>          
+>>> The problem of delta rpm is the work need to generated alls delta and
+>>> the space need on mirrors to host everything.
+>>> We must provide delta for each version to the next one:
+>>>
+>>> - main foo-1
+>>> - upd  foo-2 D: 1->2
+>>>          foo-3 D: 2->3 and 1->3 ?
+>>>          foo-4 D: 3->4 and 1->4, 2->4 ?
+>>>
+>>>        
+>> I would make all delta updates relative to the distro release, i.e.
+>> - main = foo-1
+>> - upd_full = foo-2, foo-3, foo-4, etc
+>> - upd_delta = foo-1>2, foo-1>3, foo-1>4, etc
+>> without foo 2>3, 2>4, 3>4
+>> (so half as many, with 3 updates.)
+>>
+>> Note that the idea is to retain full update packages, the delta updates
+>> being a file-by-file diff of contained files (probably in their own
+>> repository).
+>>      
+> That mean people udapting frequently their distribution will not profit
+> of delta rpm, then downloading the full rpm as soon they made one
+> update.
+>
+> Delta rpm will become not so usefull then, except for new install.
+>    
+Don't think so.  I follow closely changes in Mozilla Seamonkey, for 
+example, and changes are very small with each update.  I would say much 
+less than 1% of the files, by the space taken.
+I think that this is typical.
+However, for much smaller programs, it could be that after cumulative 
+updates, the delta update is the same size as a full update - but never 
+bigger (except maybe a few bytes).
+>>> etc...
+>>> What if delta 1->4 is bigger than the package itself ? and for 2->4 ?
+>>>
+>>>        
+>> Highly improbable, as I conceive it.
+>> If foo-1.rpm contains files fooa foob fooc food, and only foob changes
+>> to foob',
+>> then full foo-2.rpm contains files fooa foob' fooc food
+>> and delta foo-2d.rpm contains only file foob', with the info that this
+>> replaces foob.
+>> And of course with this model, there is no 2->4.
+>>      
+> Changes between 1->4 will probably be bigger than 2->4 as there is more
+> changes between them.
+>    
+Evidently.  The deltas will tend to become bigger with each update.  But 
+remaining generally much smaller than a full update.
+>>> Delta rpm is hard to manage (any volunteer to write the tools to manage
+>>> this ?) and as bonus, I am not sure it is still compatible with our
+>>> current rpm...
+>>>
+>>>        
+>> To create a delta rpm, one only needs the new full version (or the
+>> proposed contents), and a script which automatically includes the new
+>> files with the references to those replaced.
+>> I'm not trying to say it is simple to write - especially since I
+>> understand that the current tools are written in Perl - which has a
+>> syntax which I barely understand.
+>> But I'd be interested in contributing to my ability.
+>>      
+> Nothing deny you to start to work on this and then submit you code. It's
+> what I did for the mirrors tools :)
+>    
+Good idea :)
+The arrival of Mageia is motivating me to contribute more, something 
+I've always put off doing with Mandriva (except to Bugzilla and forums).
+Maybe I can find a language a bit more friendly (to me) than Perl ?
+> We'll see when BS and SVN will be ready to merge it if it works.
+>    
+>>> Just think we don't have an infinite space on mirror. Even the sound
+>>> good, please try to estimated the cost it can be per release.
+>>>
+>>>        
+>> I agree it would take more space on mirrors, but as full updates take
+>> much less space than the release,
+>> delta updates would take considerably less space the full updates.
+>> Also, the lower bandwidth to download for users would also benefit the
+>> mirrors.
+>>      
+> You know, most of our rpms are less than 10MB, but du -sh is clear, the
+> distribution is around 35GB per arch.
+>
+> Nothing is really big on mirrors, but the results is.
+>    
+But if we can reduce 10MB updates to 1MB, that would be a big benefit 
+for downloading updates.  Especially for low bandwidth users.
+And I think that the % update will likely be much more than that.
+Don't forget that commercial updates (often erroneously referred to as 
+patches) are often delta (by file) updates, as being proposed.
+
+- André
+