Infrastructure/PrestoBuildsysIntegration

From FedoraProject

< Infrastructure(Difference between revisions)
Jump to: navigation, search
m (1 revision(s))
m (Categorize)
 
(One intermediate revision by one user not shown)
Line 4: Line 4:
  
 
== Summary ==
 
== 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.
+
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 [[Releases/FeaturePresto|  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.
 
In order for our users to be able use [[Releases/FeaturePresto|  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.
Line 44: Line 44:
  
 
'''Note:''' We've managed to work out how to attach rpm signatures to deltarpms after deltarpm creation, so this is no longer an issue.
 
'''Note:''' We've managed to work out how to attach rpm signatures to deltarpms after deltarpm creation, so this is no longer an issue.
 +
 +
[[Category:Infrastructure]]

Latest revision as of 22:08, 8 January 2010

Contents

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