Yum-presto 0.3.9 - FC6 *and* Rawhide

[Michael Wiktowy]

On 4/15/07, Thomas M Steenholdt <tmus at tmus.dk> wrote:
> This is probably something that sould probably be debated for the
> official inclusion of presto in F8(?)... Do we want to generate
> deltarpms for any possible delta, allowing a deltarpm update, using
> presto, to latest release regardless of the currently installed version?
> Or do we only want the deltarpm from the previous release to the newest,
> from base version to newest or what should the policy be here?
>
> I'd personally like to see that we had all possible deltas on the
> mirrors. To make sure we save on every update and not only some.

Keeping every single combination of delta upgrades would quickly add
up to a lot of files taking a lot of space with most of them
completely unused after a short while.

I would suggest the sane way to generate delta rpms would be to catch
two groups of people: those who freshly installed the OS from released
media and those who are keeping up to date by checking periodically
for updates.

For the first group of users, keep one delta rpm around for each
package that is the diff between the first released rpm version (ie.
the version on the original install media and core repo) and the
latest version in updates. This one file per package would be replaced
each time an update occurs.

For the second group of users, keep a diff from the last update to the
current one for each package. The replacement of these would be a
little more complex to avoid losing delta updaters when multiple
updates to the same package happen in a very short period of time. You
would have to decide what is a reasonable amount of time to allow
people to apply updates. If updates to a package happen multiple times
within this time period, keep them all and let them get deleted as
that time window passes.

This way, at a minimum (and typically), you are keeping two diffs per
updated package. At a maximum, there are a few more kept around
temporarily to accomodate oops-ed releases or back-to-back quick
fixes. These extra ones are likely to be small anyways since rapid
releases generally mean small changes.

I am not sure what format of diffs presto can handle now, but it would
likely be better for the source and mirrors if the multiple
incremental updates were kept in the format A->B, B->C, C->D, etc.
instead of A->B, A->C, A->D, etc. That way, when a new update comes
out, only a new file has to be generated and mirrored. Presto would
have to know how to download and chain together a bunch of diffs to
bridge versions though.

Just my thoughts on an excellent project.

/Mike