Integrating deltarpm creation

Jeremy Katz katzj at redhat.com
Thu Jun 21 20:18:35 UTC 2007


One of the things that we're looking at for Fedora 8 is how to integrate
deltarpms and the presto yum plugin so that we can reduce the amount
that our users have to download.  To make this happen, though, is going
to require some work on the side of the build system and compose tools
so that we can generate these without any real problems.  Based on the
discussion Jesse and I were having driving home yesterday, we came to
the following as a proposal.  (Note: any errors here are probably mine
since I transcribed it a while after the conversation).

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.

To handle the case of deltas for updates, we can have a step either
happen pre-mash or early in mash to call out to koji to create deltas.
We'll want to be creating the delta for dist-fX-GA -> the update as well
as the latest package in dist-FX-updates and including them.  We then
just need to generate the delta metadata and do modifyrepo much like
we'll be doing for the updateinfo.

Updates-testing can basically work identically to updates.

Generating deltas for rawhide is a little trickier.  The idea we got to
was that we'd change dist-rawhide to not inherit and instead be tagging
packages with it.  Then, for the packages we tag, we can also generate a
delta from the last dist-rawhide version to the new version.  Then mash
can pull off of the dist-rawhide tag (like now) and use deltas much like
the update case

What do people think?  Entirely crazy?  Just a little bit crazy?  Has
holes big enough to drive a truck through?

Jeremy




More information about the buildsys mailing list