The cost of a solution produced by the interactive dependency resolver is a value that aptitude uses to determine how “bad” that solution is. Solutions that are “better” are always displayed before solutions that are “worse”. The cost of solutions is defined in the configuration option Aptitude::ProblemResolver::SolutionCost.

Some typical costs are shown in Example 2.1, “Sample resolver costs”.

safety, priority

removals, canceled-actions

removals + 2 * canceled-actions

As can be seen from the above examples, a cost is not necessarily a single number. In fact, a cost consists of one or more cost components, each of which is a number associated with the solution. When sorting solutions, the resolver examines cost components in order, proceeding to later components only if the earlier ones are equal. For instance, in the cost “removals, canceled-actions”, solutions with fewer removals always appear before solutions with more removals, regardless of how many canceled actions they have. However, solutions with the same number of removals are sorted so that solutions with fewer canceled actions appear first.

Cost components come in two flavors: basic cost components and compound cost components.

Basic components simply name some property of the solution, such as “upgrades” or “removals”. A list of built-in basic components provided by aptitude can be found in Table 2.1, “Basic cost components”. You can also create your own cost components using the add-to-cost-component and raise-cost-component hints; see the section called “Configuring resolver hints” for details.

Each basic component is either a counter or a level. Counters count how many of a solution's actions meet some condition (such as removing packages or installing new packages), while levels associate a number with each action and compute the highest number associated with any action in the solution.

Compound components are built by combining the values of basic components. For instance, removals + canceled-actions adds the components removal and canceled-actions, resulting in a component that counts the number of removals and canceled actions. Compound components combine counters by adding them together and levels by taking their maximum value, as shown in Figure 2.11, “Syntax of compound cost components”.

	Note
	It is an error to add two levels, or to take the maximum of two counters, or to combine levels and counters in any way. For instance, the costs removals + safety and max(upgrades, installs) will be treated as errors and ignored by the resolver.[13]

                [scale1]*cost1 + [scale2]*cost2 + ...
              

                max([scale1]*cost1, [scale2]*cost2, ...)
              

Note that each individual basic component can be multiplied by a scaling factor before it is combined with other components. This can be used to control the trade-offs that the resolver makes between costs. For instance, a cost of 2*removals + 3*upgrades says that three removals are exactly as “bad” as two upgrades. Solutions that contain four removals and one upgrade will be considered equivalent to solutions containing one removal and three upgrades, since both have a cost of eleven.

Figure 2.12. Safety cost levels

The safety cost component is a heuristic estimate of how “safe” or “unsafe” a solution is. Safety costs can be thought of as a way of dividing solutions into several numbered “levels”, where “less safe” levels are given higher numbers. Figure 2.12, “Safety cost levels” shows how this works with aptitude's default settings.

	Tip
	Safety cost levels are just one way to control the order in which dependency solutions are returned. See the section called “Costs in the interactive dependency resolver” for a full description of how to change the order in which aptitude sorts solutions.

By default, aptitude initializes the resolver with a “reasonable” set of safety cost levels. They are:

If a solution qualifies for several safety cost levels, it will be placed in the highest one, that is, the one that appears last. For example, a solution that upgrades one package to its default version and breaks a hold on a second package will be placed at level 40,000. You can adjust the levels of individual versions using resolver hints; see the section called “Configuring resolver hints” for details. The default levels are illustrated in Figure 2.12, “Safety cost levels”.