RPM Upgrade SOP

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m
Line 1: Line 1:
 
== Description ==
 
== Description ==
<!-- Put a description of the task here.
+
When upgrading rpm with backwards incompatible changes we need to take a few steps to ensure that we transition smoothly.  For both users and the buildsystem.
-->
+
When upgrading rpm with backwards incompatible changes we need to take a few steps to ensure that we transition smoothly.  For both users and the buildsystem.
+
 
+
  
 
== Action ==
 
== Action ==
<!-- Describe the action and provide examples
 
-->
 
 
* build the rpm with new features in rawhide (we need to wait 2 (two) weeks before defaulting to new features.)
 
* build the rpm with new features in rawhide (we need to wait 2 (two) weeks before defaulting to new features.)
 
* build a new rpm with the new features for the buildsystem (we need to test that it wont break anything for older releases).  the buildsystem host rpm installs the packages into the chroot. so it needs to be able to handle the new rpms.
 
* build a new rpm with the new features for the buildsystem (we need to test that it wont break anything for older releases).  the buildsystem host rpm installs the packages into the chroot. so it needs to be able to handle the new rpms.
Line 18: Line 13:
 
* build the needed redhat-rpm-macros in a rawhide tag
 
* build the needed redhat-rpm-macros in a rawhide tag
 
* build packages in all releases.
 
* build packages in all releases.
 
  
 
== Verification ==
 
== Verification ==
<!-- Provide a method to verify the action was successful
 
-->
 
 
* check the rpms from the test buildsystem to make sure that they have the needed rpm features.
 
* check the rpms from the test buildsystem to make sure that they have the needed rpm features.
  
== Considerations ==
+
== Consider Before Running ==
<!-- Create a list of things to keep in mind when performing action.
+
-->
+
 
* Should SRPMS be changed? if not try to keep backwards compatibility.
 
* Should SRPMS be changed? if not try to keep backwards compatibility.
 
* will buildsystem code changes be needed to support the new feature (i.e. noarch subpackages).  If so this needs much longer planning  and coordination with the koji devs.
 
* will buildsystem code changes be needed to support the new feature (i.e. noarch subpackages).  If so this needs much longer planning  and coordination with the koji devs.

Revision as of 17:15, 8 January 2010

Contents

Description

When upgrading rpm with backwards incompatible changes we need to take a few steps to ensure that we transition smoothly. For both users and the buildsystem.

Action

  • build the rpm with new features in rawhide (we need to wait 2 (two) weeks before defaulting to new features.)
  • build a new rpm with the new features for the buildsystem (we need to test that it wont break anything for older releases). the buildsystem host rpm installs the packages into the chroot. so it needs to be able to handle the new rpms.
  • issue updates for stable release that support the new features where possible.
  • After 2 weeks in rawhide and the buildsystem has been tested and verified to be ok with the change can the changes to rpm macros be triggered.

Build system Verification

  • setup a test koji instance
  • install new rpm on host and setup external repos for supported releases.
  • build the needed redhat-rpm-macros in a rawhide tag
  • build packages in all releases.

Verification

  • check the rpms from the test buildsystem to make sure that they have the needed rpm features.

Consider Before Running

  • Should SRPMS be changed? if not try to keep backwards compatibility.
  • will buildsystem code changes be needed to support the new feature (i.e. noarch subpackages). If so this needs much longer planning and coordination with the koji devs.