Description of the CUDF Format

This document contains several related specifications, together they describe the document formats related to the solver competition which will be organized by Mancoosi. In particular, this document describes: - DUDF (Distribution Upgradeability Description Format), the document format to be used to submit upgrade problem instances from user machines to a (distribution-specific) database of upgrade problems; - CUDF (Common Upgradeability Description Format), the document format used to encode upgrade problems, abstracting over distribution-specific details. Solvers taking part in the competition will be fed with input in CUDF format.

💡 Research Summary

The paper “Description of the CUDF Format” presents a comprehensive specification for two document formats—DUDF (Distribution Upgradeability Description Format) and CUDF (Common Upgradeability Description Format)—that serve as the backbone of the Mancoosi solver competition. The authors begin by motivating the need for a distribution‑agnostic representation of upgrade problems. Existing package managers (apt, yum, zypper, etc.) each expose their own metadata schemas, making it difficult to compare solver performance across different Linux distributions. To address this, the paper introduces DUDF as a lightweight, distribution‑specific container that captures the exact state of a user’s system, including installed packages, available versions, and the raw dependency/conflict information as emitted by the native package manager. DUDF instances are collected from user machines and sent to a central repository where they are transformed into the abstract CUDF representation.

CUDF is defined as a formal, distribution‑independent language for describing upgrade problems. Its data model consists of two main sections: a list of packages and a request describing the desired final state. Each package record contains seven mandatory fields: name, version, depends, conflicts, provides, installed, and keep. The depends and conflicts fields are logical expressions built from conjunctions (AND) and disjunctions (OR) of version constraints, using operators such as =, !=, <, >, <=, >=. Provides allows a package to expose virtual capabilities, enabling flexible dependency resolution across different implementations. The installed flag indicates whether the package is present in the initial system state, while the keep field encodes policies for preserving or removing packages during solving.

The request section enumerates three explicit actions—install, remove, and upgrade—each expressed as a list of package identifiers optionally accompanied by version constraints. In addition, CUDF supports an “optimize” clause that lets problem submitters specify one or more objective functions. The current specification includes three canonical objectives: minimize the number of installed packages, minimize total download size, and minimize version changes. These objectives can be combined hierarchically or weighted, giving solvers the ability to produce solutions that are not only feasible but also optimal with respect to user‑defined criteria.

Two serialization formats are defined for CUDF: a JSON representation optimized for machine parsing and an RFC822‑style text representation designed for human readability. Both formats are accompanied by a strict schema and validation tools that reject malformed inputs with detailed error messages. The paper also describes the core computational primitives required by any CUDF‑compliant solver: a version comparison function that normalizes and orders version strings, a logical expression parser that builds abstract syntax trees for dependency formulas, and set‑theoretic operations for manipulating candidate package selections.

The competition workflow is outlined in five steps: (1) a user’s system generates a DUDF file, (2) the DUDF is uploaded to a central server, (3) the server runs a distribution‑specific parser to translate DUDF into CUDF, (4) the CUDF instance is fed to participating solvers, and (5) solvers return a CUDF‑encoded plan that can be applied back on the user’s machine. This pipeline ensures that all solvers receive identical, distribution‑neutral inputs, enabling fair benchmarking.

Finally, the authors discuss future extensions. They propose adding multi‑architecture support, explicit security‑update annotations, and a plug‑in mechanism for custom optimization goals. They also emphasize the importance of open‑source reference implementations for both the DUDF‑to‑CUDF translators and the CUDF parsers, to foster community adoption and to guarantee reproducibility of competition results.

In summary, the CUDF specification abstracts away distribution‑specific details while preserving the full expressive power needed to model real‑world package upgrade scenarios. By providing a rigorous, validated, and extensible format, the paper lays the groundwork for systematic evaluation of upgrade solvers, promotes interoperability among different Linux ecosystems, and opens avenues for advanced research in dependency solving, optimization, and automated system maintenance.