Conary:Update and Migrate

From rPath Wiki

This page describes the differences between conary update and conary migrate.

Functionality

As the manual page describes, conary migrate is useful in situations where a group defines exactly the set of packages to be installed on the system. As such, it will erase everything that is not referenced by the groups specified on the command line.

In contrast, conary update is useful in situations where more fine-grained changes are desired to be performed.

The update operation is user-centric; this means it will try to preserve the changes the user performed on the system as much as possible. For instance, in a desktop deployment scenario, users want the ability to install troves from various sources, and the update should respect the user's choice.

The migrate operation is designed to bring the appliance as close as possible to how the appliance vendor intended it to be. One could think of this mode of operation as being vendor-oriented.

The migrate operation is significantly easier to compute, since the target state of the system is known from the very beginning. On the other hand, update has to look very closely at the state of the system in order to determine what the final state is supposed to be.

Terminology

• Top-level trove: a trove that is not referenced by other troves on the system. These are all troves that don't have the same flavor or branch as any trove that's included in an installed group.
• byDefault=False: when including a trove into a collection, the packager has the opportunity to decide if installing the collection will automatically install the trove (byDefault=True) or it will skip the installation (byDefault=False).
• Dark-site environment: A highly confined deployment scenario where the appliance does not have Internet access. Updating such a deployment usually requires the use of removable media.

Other differences

• migrate erases all troves not referenced in the groups specified. However, it will preserve installed troves that were originally byDefault=False.
• Explicit erase operations can be part of the update job. The trove specification for update allows one to add troves while removing others (by prefixing the trove name with a dash). This syntax is not available for migrate
• update will follow a user's preference to not have a specific trove installed by omitting it from the update process. In contrast, migrate reinstalls all locally erased troves that are referenced in the parent collection as byDefault=True (in a similar manner to what {{command|conary sync</tt> does).
• Internally, migrate uses absolute changesets.
• migrate is a much more reliable method to maintain deployed appliances, especially in dark-site deployments. To illustrate a difference in the way update and migrate handle trove selection, consider the case where a trove's version changed to a different branch. In that case, update will not work in a dark-site environment, since it will try to access the network, whereas migrate will ignore the user's change and bring the system back to the intended state.
• migrate is equivalent to freshly installing the top-level group(s) on a bare system (with the exception of byDefault=False components which were already installed, and will be preserved).

Conclusion

Although similar, the two operations address different use cases. The migrate uses a much simpler algorithm, and is therefore better suited for maintaining appliances.