Infrastructure/UpdateSystem

Fedora Package Updating System [DRAFT]

Luke Macken <lmacken@redhat.com>

Current Update Lifecycle

Core

• Core CVS -> Brew (Red Hat Internal build system) -> Fedora Update System (currently internal) -> Mirrors

Extras

• Extras CVS -> Plague ( Fedora Extras Buildsystem ) -> Mirrors

Legacy

• http://cvs.fedora.redhat.com/viewcvs/?root=legacy -> Plague ( Fedora Legacy Buildsystem )-> Mirrors

Next Generation Update System

These proposed changes will consolidate the package updating process for Core, Extras, and Legacy, allowing packages for any of the three trees to be updated using the same tool -- while still staying buildsystem independent. This infrastructure will aid in opening the Core package update process to the community as well.

Ideal Workflow

Package updating

• Command line submission: make fedora-update
• Web submission
• CVS Integration? Allow dev edit specs, add/remove patches with ease, and commit/tag updates through a web interface.

Building

• xmlrpc submission to plague/brew for building.
• somehow monitor when a build successfully completes and add it to the pending update queue.

Pending Update Stage

• Automatic QA of packages before they are submitted to the release team for signing/pushing
• fedora-qa, rpmlint, rpmdiff, repoclosure, etc.

Submitted to Release Team

• Release team signs package (until we get a signing server) and tells the updates system to 'Push'

Pushing

• Moves packages to proper fedora-stage
• Header generation
• Generate/insert extended update metadata
• Sync to mirrors
• Send update announcement mail

Moving packages from Testing to Final (via dev intervention)

• Move rpms to final stage directory
• regenerate/reinsert metadata
• Send update announcement mail