0.26.0

Configuration changes

Distribution section

The distro section has been updated to better reflect repository and release semantics:

• distro.version renamed to distro.release — the value now represents the feed year (e.g., 2024) rather than a package version. The old version key is still accepted as an alias.
• distro.release accepts integers — YAML values like release: 2024 (without quotes) are now handled correctly.
• distro.channel simplified — the channel value is now just the stability tier (e.g., edge, stable) instead of a codename-prefixed value (e.g., apollo-edge).

New distro.repo section

Repository configuration has moved from the sdk section to distro.repo:

distro:
  release: 2024
  channel: edge
  repo:
    url: https://repo.avocadolinux.org # optional, this is the default
    releasever: 2024/edge # optional, derived from release/channel when omitted

The entire repo section is optional. When omitted, url defaults to https://repo.avocadolinux.org and releasever is derived from {release}/{channel}.

This replaces the deprecated sdk.repo_url and sdk.repo_release fields, which continue to work as fallbacks.

New cli_requirement field

A new top-level cli_requirement field allows configurations to declare the minimum CLI version required:

cli_requirement: '>=0.26.0'

If the running CLI does not satisfy the requirement, an error is raised with an upgrade prompt. Uses semver requirement syntax.

Package version wildcards

Package version specs have been simplified from template expressions to wildcards:

# Before
packages:
  avocado-runtime: '{{ avocado.distro.version }}'

# After
packages:
  avocado-runtime: '*'

Repository scoping is now handled via --releasever and lock file pinning.

SDK image tag format

The SDK image tag now includes both the release and channel:

# Before
sdk:
  image: docker.io/avocadolinux/sdk:{{ avocado.distro.channel }}

# After
sdk:
  image: docker.io/avocadolinux/sdk:{{ avocado.distro.release }}-{{ avocado.distro.channel }}

New environment variables

Environment variable	Config equivalent	Replaces (legacy)
AVOCADO_REPO_URL	distro.repo.url	AVOCADO_SDK_REPO_URL
AVOCADO_RELEASEVER	distro.repo.releasever	AVOCADO_SDK_REPO_RELEASE
AVOCADO_DISTRO_RELEASE	distro.release	---
AVOCADO_DISTRO_CHANNEL	distro.channel	---

Legacy environment variables continue to work as fallbacks.

Repository path format

The releasever is now derived as {release}/{channel} (e.g., 2024/edge, 2024/stable). This can be overridden explicitly via distro.repo.releasever or the AVOCADO_RELEASEVER environment variable.

CLI changes

avocado install — imperative package management

avocado install now supports adding specific packages to a scope:

# Sync all sysroots with config (existing behavior)
avocado install

# Add packages to an extension
avocado install curl iperf3 -e my-app

# Add packages to a runtime
avocado install my-package -r dev

# Add packages to the SDK
avocado install nativesdk-cmake --sdk

# Add without writing to avocado.yaml
avocado install curl -e my-app --no-save

When packages are specified, exactly one scope flag is required: -e/--extension, -r/--runtime, or --sdk. Packages are written to avocado.yaml by default (use --no-save to skip).

New avocado uninstall command

Remove packages from an extension, runtime, or SDK:

avocado uninstall curl iperf3 -e my-app
avocado uninstall my-package -r dev
avocado uninstall nativesdk-cmake --sdk

Packages are removed from avocado.yaml and the sysroot is reconciled automatically.

avocado deploy — updated device format

The --device flag now accepts [user@]host[:port] format:

avocado deploy -r dev -d root@192.168.1.100:2222

Bug fixes

• Fixed seamless switching between extension source types (package/path/git).
• Fixed path and git external extensions not bumping the release build manifest.
• Fixed extension config lookup for template extension names (e.g., {{ avocado.target }}).
• Fixed cp preserving SELinux xattrs on overlay2 during extension package/build.
• Fixed deploy lifecycle for real hardware targets.
• Improved error handling for missing extension versions and unparseable remote configs.
• Improved stamp validation error formatting with [ERROR]/[INFO]/[WARNING] tags.

Improvements

• SDK compile deps and extensions are now filtered by active runtimes.
• Extension images support configurable filesystem types (squashfs/erofs).
• Wildcard extension versions are resolved from the RPM database for remote extensions.
• Content-addressable images for deploy.
• TUF repository initialized on provision.

Migration guide

Before (0.25.x)

distro:
  version: 0.1.0
  channel: apollo-edge

runtimes:
  dev:
    packages:
      avocado-runtime: '{{ avocado.distro.version }}'
    extensions:
      - app
      - avocado-ext-dev
      - avocado-bsp-{{ avocado.target }}

sdk:
  image: docker.io/avocadolinux/sdk:{{ avocado.distro.channel }}
  packages:
    avocado-sdk-toolchain: '{{ avocado.distro.version }}'

After (0.26.0)

cli_requirement: '>=0.26.0'

distro:
  release: 2024
  channel: edge

runtimes:
  dev:
    packages:
      avocado-runtime: '*'
    extensions:
      - app
      - avocado-ext-dev
      - avocado-bsp-{{ avocado.target }}

sdk:
  image: docker.io/avocadolinux/sdk:{{ avocado.distro.release }}-{{ avocado.distro.channel }}
  packages:
    avocado-sdk-toolchain: '*'

Steps

1. Update distro section: rename version to release and change the value to the feed year (e.g., 2024). Update channel to the stability tier only (e.g., edge instead of apollo-edge).
2. Update SDK image tag: change {{ avocado.distro.channel }} to {{ avocado.distro.release }}-{{ avocado.distro.channel }}.
3. Replace template version specs with wildcards: change '{{ avocado.distro.version }}' to '*'.
4. (Optional) Move repo config: move sdk.repo_url to distro.repo.url and sdk.repo_release to distro.repo.releasever.
5. (Optional) Update CI environment variables: rename AVOCADO_SDK_REPO_URL to AVOCADO_REPO_URL and AVOCADO_SDK_REPO_RELEASE to AVOCADO_RELEASEVER.
6. (Optional) Add CLI version gating: add cli_requirement: ">=0.26.0" at the top level to enforce the minimum CLI version for your project.

info

All old config keys and legacy environment variables still function as fallbacks, so migration can be done incrementally.