Appliance Development:Adopting and Adapting
From rPath Wiki
Developers often adopt packages or groups in an appliance and sometimes adapt them to better fit the appliance needs. This saves the effort of repackaging the same software and can ensure consistency across appliances.
Adopting: Add to a Group
Developers can adopt any accessible packages and groups from any repository by adding them to a group recipe. Some possible considerations when adding a package or group are:
- The stability of the label or branch from which it is included
- The setLabelPath or setSearchPath from which the appliance will resolve dependencies for this and other troves
- Whether the version included should be the latest version available or restricted to a particular version (use setSearchPath from the group recipe classes to lock in versions, such as when using a specific version of rPath Linux)
Adapting: Shadow or Derived
Developers can copy packages and groups and modify them for the specific needs of an appliance. These copies are made by making a shadow, which is capable of merging updates from its parent at any time.
When minimal modifications are needed, rPath recommends using the derived package feature described in Conary:Derived Packages. When more extensive changes are needed, the shadow can be used in its entirety. In both options, shadow the trove to a label where the modified package or group should reside. Then, check out the shadow to work with the files and recipe that make up that trove.
 | Use the Shadow or Derive? section in Conary:Derived Packages to help determine whether to use the entire shadow or to create a derived package. |
In the following example, a developer on project example is shadowing a package named pkg from conary.rpath.com@rpl:1 to example.rpath.org@corp:devel:
$> cvc shadow example.rpath.org@corp:devel pkg=conary.rpath.com@rpl:1
The developer then checks out the package to make modifications:
$> cvc co pkg
Note that the developer does not need to use the cvc commands for creating a new package
For derived packages, modify the files using the steps and recipe instructions in Conary:Derived Packages. Anything that is not modified should be removed, and use the DerivedPackageRecipe class as instructed to provide only recipe lines that require modification.
For complete shadows, work with the checked out files just as with developing new packages. Step through the Shadowing and Cloning Tutorial for guided practice in this activity. Use the links from the Conary Branches page as a reference and instructions for cvc commands used to shadow, clone, merge, and compare revisions.
After the trove is modified, the developer cooks the recipe, tests the changes, commits the updated files, and cooks the package; this process is the same as for developing new packages.
Cautions
Before adopting or adapting packages and groups, considering the impact of the following:
- The licensing of the packaged software:
- Licensed software requiring a customer purchase
- GNU General Public License (GPL) software
- Ongoing maintenance of adapted packages on an upstream branch (shadows)
- Incorporating upstream changes to an appliance