Integrating deltarpm creation

[Mike McLean]

Jeremy Katz wrote:
> The first thing is that it makes the most sense for the deltas to be
> created and stored by koji rather than as a secondary process.  This
> adds the advantage that they're stored consistently with the packages
> and also can be cached rather than recreated every time.  It feels
> somewhat analagous to me to the current situation with signing.

While I see the semi-parallel with signatures, I'd rather not rush into 
adding this to koji. I'd like to have a better understanding of how 
these deltas need to be managed.

Do we anticipate Koji actually having a use for the deltas, or would it 
just be storing them for other tools?

Can deltarpms be signed independently of the rpms it compares? If so, we 
may need to think about tracking these signatures.

How should we deal with the delta/signature interaction? Is there a 
quick way to read the target's signature info from the delta (applydelta 
-i doesn't seem to report it)? Each rpm in koji can have multiple 
signatures, and we would presumably care which signature will be used 
for the target rpm in the delta. This leads me to wonder about naming 
schemes and api needs.

With signatures, the cached files are tiny, there are unlikely to be 
more than a handful of them per rpm, and it is clearly reasonable to 
keep them for as long as the rpm is kept. Even deltas for trivial cases 
seem to be much larger than a cached signature header, and one can 
imagine accumulating a large number of deltas for an rpm. So the 
question is, how long should deltas be kept, and what should trigger 
their removal?