Latest revision as of 22:08, 8 January 2010

[edit] DeltaRPM integration into the Fedora build system

[edit] 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.

[edit] Possible methods of integration

[edit] 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.

[edit] 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

[edit] 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.