Request for Comments: updating RPMs using binary deltas

[Nigel Metheringham]

On Fri, 2004-01-09 at 15:13, Lamar Owen wrote:
> IMO the consequences are minimal for mirror operators.  Developers of update 
> tools (like yourself) would have more of a job; and that is probably why you 
> are in principle opposed since it would create more work for you as a 
> developer.  But not as a mirror op.  It would be a one-time pain to develop 
> the algorithm.  The build hosts of course have to generate the deltas.  This 
> may or may not be difficult.  I see a single program doing the job that gets 
> run post build on the two trees (much like a diff -r) and generates the tree 
> of deltas.  This same tool could even be used by mirrors to pull only the 
> deltas and locally regenerate the larger full updates.  There is, however, 
> the signature issue there, so that might not be easily workable.

The signature issue is pretty easy.
You make a tool that builds a rpm-patch file between 2 signed rpms. 
Application of the rpm-patch tool to the base rpm and the rpm-patch file
will create a whole signed rpm identical to the original update rpm
file.  If it can't do this then its not worth bothering with.

[...]

> You have yet to prove that it would create an _enormous_ amount of complexity 
> or cost _a_lot_ of development time.  But the bandwidth fruit for the end 
> user is anything but questionable, if we can get better patch to noise ratio 
> than SuSE is getting, which is already pretty good.
> 
> So your view is that your time is more valuable than the end user's time and 
> frustration, particularly if they have poor ISPs.  That is how it sounds, 
> whether that is your intention or not.  I can see users that will use SuSE 
> simply because they do this.

We have got to the stage where you need to provide a proof of concept. 
The community does not work by people hassling developers to get their
pet projects done especially when those have serious implications,
instead someone has to come up with proof of concept code.  Since you
are the one who is desperate for this I look forward to you writing or
sponsoring the code.

	Nigel.

-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]