This section presents a selection of CoSyE criteria and given the mapping to PB criteria and MOF (for a full description see appendix B). These criteria are presented in three categories, minimising change to the system, minimising the out-of-dateness of the system and minimising the number of versions of packages installed. The minimising change criteria were developed by Mancoosi for MISC4 and the criterion used to minimise the out-of-dateness was developed for Eclipse P2 solver (Rapicault and Le Berre, 2010).
5.2.1 Change Criteria
Simple definitions of criteria to minimise change can often have negative effects during CSE. For example, the most direct measurement of change of a component system is the measurement of the total changed components. This is defined as a CoSyE criterion:
Definition 28 The changed components criteria is defined as critcompsChanged =
hrankαcompsChanged,≤i, where rankαcompsChanged(β) =|α∆β|.
That is, the number of components in the symmetric difference between component systems is the minimised with this criterion. This criterion’s measurements are a coarse representation of the risks of changing a system. For example, a component being replaced by another version of itself is intuitively less risky than it being replaced
4
with an entirely different component. Yet using the critcompsChanged criterion, these
would be seen as equivalent changes.
To define a change criterion that takes into account changing between components of the same name, is less risky, a components name can be considered. For this purpose the functionV is defined:
Definition 29 The function V : 2C× N → 2C takes a set of components α and a
component name n, and returns a set of components with name n that are in α, i.e. V(α, n) ={hn0, vi | hn0, vi ∈α andn0 =n}
This function can be used to define a criterion that considers the name of a component:
Definition 30 Thechangecriterion is defined as critchange=hrankαchange,≤i, where
rankchangeα (β) =|{n|n∈ N and V(α, n)6=V(β, n)}|.
This criterion can be altered to also consider new and removed component names: Definition 31 The new criterion is defined as critnew = hrankαnew,≤i, where
ranknewα (β) =|{n|n∈ N and V(α, n) =∅ andV(β, n)6=∅}|.
Definition 32 The removed criterion is defined as critremoved = hrankremovedα ,≤i,
where rankremovedα (β) =|{n|n∈ N and V(α, n)6=∅ and V(β, n) =∅}|.
The change, new and remove criteria were taken directly from the MISC competitions definition of criteria.
The mapping between these criteria, PB criteria and MOF are presented in table 5.2. A full description of the mapping is presented in appendix B.
MOF name CoSyE criterion PB criterion
-changed critchange=hrankchangeα ,≤i hfchange, <, Ichangei -removed critremoved=hrankremovedα ,≤i hfremoved, <, Iremovedi
-new critnew=hranknewα ,≤i hfnew, <, Inewi
Table 5.2: Mapping of the change, removed and new criteria between MOF, CoSyE and PB
5.2.2 Out-of-date Criteria
When changing a component system it is a good idea to select more recent versions of components, as they keep the system from becoming out-of-date. However, it is a
difficult task to define an appropriate measurement of how out-of-date a component system is. This difficulty comes from two properties of component versions must be considered:
• A version of a component can only be compared to version of another component with the same name, i.e. given two components hn, vi and hn0, v0i comparing v and v0 is only useful ifn=n0.
• The sum of versions is not a useful metric as two lesser versions will not be better than one greater version, e.g. given componentshn,2i,hn,3iandhn,4i, a system with onlyhn,2i andhn,3i is not better than a system with justhn,4i.
Not considering these properties when defining criteria could lead to significant problems.
A useful criterion has been defined in Eclipse P2 that minimises a measurement of the out-of-dateness of a component name. This measure of out-of-dateness counts the amount of components that is a greater version than a component currently installed. It is defined as:
Definition 33 The function uptodatedistance takes a component hn, vi and a set of componentsCtand returns the number of components with the same name and a greater
version, i.e. uptodatedistance(hn, vi,Ct) =|{hn, v0i | hn, v0i ∈Ct and v0 > v}|
A criterion using this measure can then be defined:
Definition 34 Given the set of components Ct, the uptodate distance criterion is
defined ascritutdd=hrankutddα ,≥i, whererankutddα (β) =
P
c∈βuptodatedistance(c,Ct).
That is, the measure to be minimised is the number of components that have the same name, and are a greater version than a component that is currently installed. This measure depends on the release of new versions to measure out-of-dateness, and it assumes that components are maintained. If a component is not maintained, and versions are never released, the component will be measured to never go out-of-date. Conversely, if a components developer releases versions very quickly, the component will become quickly out-of-date. These problems can be solved through community effort to maintain and release components, as is attempted for Debian systems (Barth et al., 2005).
The mapping between this criterion, MOF and the PB criteria is presented in table 5.3, with a full description in appendix B.
MOF CoSyE criterion PB criterion
-uptodatedistance critutdd =hrankαutdd,≥i hfutdd, <, Iutddi
Table 5.3: Mapping of the up-to-date distance criterion between MOF, CoSyE and PB
5.2.3 One Version per Package Criteria
As discussed in the previous chapter, the restriction that Ubuntu systems must have only one version of each package installed is not enforced by the component constraints. This restriction can however be encouraged by defining a criterion that minimises the amount of packages with multiple versions.
Definition 35 Given the set of components Ct, the One Version per Package
criterion is defined ascritovpp=hrankαovpp,≥i, where rankαovpp(β) =Pn∈N|V(β, n)|>
1.
That is, this criteria minimises the number of package names that have more than one version installed.
The mapping between this criterion, MOF and the PB criteria is presented in table 5.4 with a full description in appendix B.
MOF CoSyE criterion PB criterion
-ovpp critovpp=hrankovppα ,≥i hfovpp, <, Iovppi
Table 5.4: Mapping of the one version per package criterion between MOF, CoSyE and PB