Personal tools
     DOCUMENTATION

Conary:Repository Maintenance

From rPath Wiki

Jump to: navigation, search

Contents

A common concern among Conary repository administrators is ensuring that the repository contains only complete builds and useful troves. For example, rBuilder project owners might want to ensure incomplete builds and untested packages do not exist in a project's repository. rPath technologies can be employed to prevent unusable content and maintain repository efficiency. This page outlines some tools and techniques used for Conary repository maintenance.

Always take a preventative approach to repository maintenance because troves cannot be removed from a repository after they are committed.

Testing with Local Changesets

Testing with local changesets can prevent committing incomplete recipes to a repository. Before committing a new or updated package, cook the package recipe locally, and use the resulting changeset to test the package. Use the following steps to create and test with local changesets.

  1. Cook the package recipe locally: cvc cook <package_name>.recipe
  2. Apply the changeset to a test system that represents a system on which the completed package will be installed: conary update <changeset_file>.ccs
  3. Step through the test cases required to ensure the package functions as desired.
  4. When changes to the package are necessary to address a failed test, roll back the test system to restore the test system to its previous state (prior to installing the changeset). Modify and recook the package in the local build environment, and apply the new changeset to test again.
  5. When the package tests successfully, commit to the repository with the assurance the package is complete and functions as desired.

Test Branches and Cloning

Adding a test branch to a release management plan can prevent placing untested packages or groups on a final production branch. A common release management strategy is to clone the trove's development branch to a test branch for testing, and cloning the successfully tested test branch to create the production branch from which the trove will be released. Cloning is used instead of shadowing in the release management plan to prevent the trove's version string from referencing its source branch.

Each time updates are made to the package or group on the development branch, a new clone to the test branch is required for testing.

The following example shows creating a clone of sample_package on an rBuilder repository example.rpath.org from the development branch rpl:1-devel onto a test branch of rpl:test in the same repository.

cvc clone /example.rpath.org@rpl:devel//test sample_package=example.rpath.org@rpl:devel//1-devel

Building with rMake

Using rMake can prevent the committing of recipes with missing or incomplete build requirements. rMake provides features for building in a local rMake repository before committing to an upstream repository. This is used to modify packages and groups existing in one or more repositories in an effort to build them in a consistent build environment, established by creating a transient chroot during the rMake build. See the rMake documentation for more information on using rMake.

Redirect Packages

Use redirect package policy to rename packages or to move packages between repositories or branches. Redirection ensures that users that have installed the old version are directed to a version that continues to be maintained. See Conary:Redirect_Package_Policy for instructions to create a redirect package for these purposes.

Shadow and Clone Considerations

Consider the impact of shadowing packages to a new label. Shadows are useful for divergent development that needs to merge changes periodically from its source branch. However, note that the version string for a package is appended with each new shadow, resulting in much longer version strings with each shadow of a shadow. Developers wanting to hide these branches or keep version strings brief might choose to clone instead of shadow. A clone can start a new branch without appending to the version string, but the clone cannot merge changes from its source branch.