Infrastructure/PrestoBuildsysIntegration

DeltaRPM integration into the Fedora build system

Summary

Note: This page is obsolete. We've essentially gone with option two (with some qualifiers). See https://fedorahosted.org/bodhi/ticket/160 for more information.

In order for our users to be able use presto , we need to have a plan on how to create and store deltarpms in the Fedora build system. A list of possible methods of doing this follows, along with pros and cons. Please feel free to add comments and/or correct mistakes.

Possible methods of integration

Build deltarpms in koji

Deltarpms would be generated in koji immediately after a package is built and pushed along with the packages using bodhi. This was the basis for Jeremy's original proposal . A ticket has been opened in koji for this.

Pros:

• Deltarpms are stored with their destination rpm and can be garbage-collected with it

Cons:

• Deciding which old rpms to create deltarpms against may be a bit difficult (am I right in thinking this?)
• We will end up generating deltarpms for packages that may not end up in updates.

Build deltarpms after package has been queued for update by bodhi

Deltarpms would be generated immediately after a package is queued for update by bodhi

Pros:

• We only generate deltarpms for rpms that will actually end up in updates.

Cons:

• We would have to manually garbage-collect the deltarpms when they're no longer needed

Deal with deltarpms completely separately

Deltarpms would be generated on a completely different server after updates have been pushed. This is the current way that the presto test repositories generate deltarpms.

Pros:

• The code is already done
• We would deal with already signed rpms when generating the deltarpms

Cons:

• Inelegant
• A nightmare for mirrors (or the master mirror would have to delay pushes even more)

Note: We've managed to work out how to attach rpm signatures to deltarpms after deltarpm creation, so this is no longer an issue.