DeltaRPM integration into the Fedora build system
Summary
Note: This page is obsolete. We've essentially gone with option two (with some qualifiers). See [1] 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.