Configuration Classes¶

Design rationale for the tolomeo_* classes: why meta-tolomeo exposes its shared configuration through a namespaced class interface rather than ad-hoc per-recipe variables.

The TLM_ Variable Interface¶

meta-tolomeo recipes once duplicated the same path and mount variables, defined ad-hoc in each recipe and again in machine configurations, with no documented interface. The tolomeo_* classes replace that with one namespaced set of TLM_ variables that an integrator can discover and override in a single place.

Every value is a weak default (?=), so a machine, distribution, or local.conf overrides it without editing a recipe. The defaults reproduce the historical hardcoded paths, so adopting the classes changes no behaviour until an integrator deliberately overrides a value.

One Source of Truth for OTA Values¶

The OTA feature spreads a set of values that must agree across several recipes — the SWUpdate bbappend, the tlm-swupdate service and its .toml, and ota-monitor. When each recipe hardcoded them independently, changing one and forgetting another broke updates silently: the package would be written to one path and looked for at another.

tolomeo_ota owns these values, and every consumer reads them. Because TLM_OTA_FILE is derived from TLM_OTA_DIR and TLM_OTA_FILENAME, overriding the directory moves the download location, the checkpoint, and the descriptor together. The coupled paths cannot drift apart because there is only one place they are defined.

Parse-Time Validation¶

Recipes that depend on machine-supplied variables need to fail loudly when those are missing. The check belongs at parse time, not in do_configure — validation is not configuration, and a do_configure check runs only after fetch and unpack, wasting that work before it reports the problem.

tolomeo_base registers a handler on the bb.event.RecipeParsed event that fails the parse when any variable named in REQUIRED_VARS is empty. Because it is a named event handler rather than anonymous Python, it is also clean under oelint.

Narrowest Class, Umbrella Front¶

The classes form a small dependency graph: tolomeo_ota inherits tolomeo_base; tolomeo_config inherits tolomeo_ota and tolomeo_install. A recipe inherits the narrowest class it needs — an OTA recipe inherits tolomeo_ota, a recipe that only installs units inherits tolomeo_install — so it pulls in only the surface it uses.

A downstream layer that wants the whole configurable interface inherits tolomeo_config, the single umbrella front. The leaf classes never inherit the umbrella, which would create a cycle.

meta-tolomeo provides the interface, the defaults, and the validation; the integrator provides the machine-specific device and filesystem variables and any overrides their hardware requires.