Aligning component upgrades

Modern software systems, like GNU/Linux distributions or Eclipse-based development environment, are often deployed by selecting components out of large component repositories. Maintaining such software systems by performing component upgrades is a complex task, and the users need to have an expressive preferences language at their disposal to specify the kind of upgrades they are interested in. Recent research has shown that it is possible to develop solvers that handle preferences expressed as a combination of a few basic criteria used in the MISC competition, ranging from the number of new components to the freshness of the final configuration. In this work we introduce a set of new criteria that allow the users to specify their preferences for solutions with components aligned to the same upstream sources, provide an efficient encoding and report on the experimental results that prove that optimising these alignment criteria is a tractable problem in practice.

💡 Research Summary

The paper addresses the problem of component upgrades in large software ecosystems such as GNU/Linux distributions and Eclipse‑based development environments. While previous work, especially the MISC (Mancoosi International Solver Competition) series, has focused on a handful of basic optimisation criteria—removed, changed, new, not‑up‑to‑date and unsatisfied‑recommends—these criteria cannot express the desire for “aligned” installations, i.e., installations where all packages built from the same source package share the same source version.

The authors introduce the notion of component alignment based on two fields that are present in Debian‑style metadata: the source name and the source‑version identifier. An installation is source‑aligned if, for every source name, all installed packages that claim that source have the same source‑version value. This captures the intuitive expectation that documentation, binaries, libraries, and related tools should come from the same upstream build, avoiding confusing mixtures such as a newer manual with an older binary or a library built from a different kernel source.

To make alignment a quantitative optimisation target, the paper defines five distinct un‑alignment measures:

1. unaligned p – the number of individual packages that are installed together with another package from the same source but a different source version.
2. unaligned pp – the number of unordered pairs of installed packages that belong to the same source yet have different source versions. This squares the impact of large clusters.
3. unaligned vc – the total number of version changes across all sources, i.e., for each source the count of distinct source versions present minus one.
4. unaligned c – the number of sources for which more than one source version is present, regardless of how many packages are involved.

The authors discuss the trade‑offs: (p) is simple but treats every mis‑aligned package equally; (pp) is more discriminating but may over‑penalise large clusters; (vc) offers a middle ground by counting distinct versions; (c) is the coarsest, ignoring intra‑cluster size. They argue that (vc) often provides a good balance between expressiveness and computational cost.

The core technical contribution is an integer linear programming (MIP) encoding of each measure that can be fed to modern MIP solvers. The encoding introduces binary variables p_i (package i installed) and i_{s,v} (any package from source s version v installed). For each alignment measure, auxiliary binary variables (nu_{p_j}, u_{p_j,p_k}, nc_s, u_s) are defined together with constraints that enforce the logical relationships:

• Package‑based unalignment: nu_{p_j} ≤ p_j and nu_{p_j} ≤ Σ_{v≠V(p_j)} i_{s,v}; plus nu_{p_j}+1 ≥ p_j + i_{s,v} for each conflicting version v.
• Pair‑based unalignment: u_{p_j,p_k} ≤ p_j, u_{p_j,p_k} ≤ p_k, and u_{p_j,p_k}+1 ≥ p_j + p_k for each pair from the same source with different versions.
• Version‑change count: nb_inst_s = Σ_v i_{s,v}; δ_s forces a 1 iff nb_inst_s ≥ 1; then nc_s = nb_inst_s – δ_s. The total unaligned vc is Σ_s nc_s.
• Cluster count: u_s is forced to 1 iff nb_inst_s ≥ 2 using constraints |V(s)|·u_s + 1 ≥ nb_inst_s and nb_inst_s ≥ 2·u_s.

The paper notes that a clausal (SAT) encoding is also possible (see Appendix).

Experimental evaluation uses a representative set of MISC problem instances (both “trendy” and “stable” tracks) ranging from a few hundred to several thousand packages, sources, and dependency pairs. For each instance the authors solve the original MISC optimisation (lexicographic combination of the five basic criteria) and then augment it with each of the four new alignment measures, one at a time. Solver runtimes are reported in seconds; most instances finish within 1 s, the slowest around 10 s, demonstrating that the additional alignment constraints do not break tractability.

A concrete example illustrates the practical benefit: a configuration containing aptitude-doc-fr 0.6.1.5-3 together with aptitude 0.4.11.11-1+b2 (different source versions) or a kernel library built from linux-2.6 version 2.6.32‑9 alongside a source package built from linux-2.6 version 2.6.30‑8squeeze1. Such mismatches can cause user confusion or even runtime incompatibilities. By minimising the chosen alignment metric, the solver prefers solutions where all packages derived from the same source share the same source version, yielding more coherent installations.

Conclusions and future work: The authors have shown that component alignment is a meaningful, expressible, and efficiently optimisable preference for upgrade planning. The MIP encoding integrates seamlessly with existing solvers and can be combined with other quality criteria (e.g., security updates, performance). Future directions include multi‑objective optimisation that balances alignment with freshness or minimal changes, dynamic alignment tracking during rolling releases, and extending the approach to other ecosystems (e.g., Maven, npm) where similar source‑version metadata may be inferred.

Overall, the paper makes a solid contribution to the field of package management by formalising a user‑centric notion of consistency and providing a practical method to enforce it in automated upgrade planning.