jdx/mise · error · eyre::Report

mise oci currently supports only apt and apk entries in [boo

Error message

mise oci currently supports only apt and apk entries in [bootstrap.packages]; unsupported manager(s): {}

What it means

Thrown by `mise oci build` when the `[bootstrap.packages]` table in mise.toml contains entries for package managers other than `apt` or `apk`. The OCI system-package layer builder (collect_package_requests in src/oci/packages.rs) can only chroot-install Debian-style apt or Alpine-style apk entries, so it collects all unsupported manager names up front, sorts and dedups them, and fails before any image work starts.

Source

Thrown at src/oci/packages.rs:192

    managers: &[ManagerPackages],
) -> Result<Option<(OciPackageManager, Vec<PackageRequest>)>> {
    let mut apk = vec![];
    let mut apt = vec![];
    let mut unsupported = vec![];
    for mgr in managers {
        if mgr.disabled || mgr.requests.is_empty() {
            continue;
        }
        match mgr.manager.name() {
            "apk" => apk.extend(mgr.requests.clone()),
            "apt" => apt.extend(mgr.requests.clone()),
            other => unsupported.push(other.to_string()),
        }
    }
    if !unsupported.is_empty() {
        unsupported.sort();
        unsupported.dedup();
        bail!(
            "mise oci currently supports only apt and apk entries in [bootstrap.packages]; \
             unsupported manager(s): {}",
            unsupported.join(", ")
        );
    }
    if !apk.is_empty() && !apt.is_empty() {
        bail!(
            "mise oci cannot mix apk and apt entries in [bootstrap.packages]; use the package \
             manager matching the selected base image"
        );
    }
    if !apk.is_empty() {
        Ok(Some((OciPackageManager::Apk, apk)))
    } else if !apt.is_empty() {
        Ok(Some((OciPackageManager::Apt, apt)))
    } else {
        Ok(None)
    }

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

Convert the unsupported entries to `[bootstrap.packages.apk]` (Alpine/Wolfi base) or `[bootstrap.packages.apt]` (Debian/Ubuntu base) so the manager matches the base image
Remove the unsupported manager tables from the config used for oci builds and install those tools as mise dev tools (`mise use node@22`, etc.) instead of system packages
Check every layered mise.toml for a stray table contributing the unsupported manager name shown in the message
Keep a dedicated mise.toml for oci builds if the same config must retain brew/dnf entries for host use

Example fix

# before (mise.toml)
[bootstrap.packages.brew]
ripgrep = "any"

# after — manager matching a Debian/Ubuntu base image
[bootstrap.packages.apt]
ripgrep = "any"

Defensive patterns

Strategy: validation

Validate before calling

// Run before invoking `mise oci build` — parse the effective config's
// [bootstrap.packages] table and allow only apt/apk keys.
fn validate_bootstrap_packages(cfg: &toml::Table) -> Result<(), String> {
    let Some(pkgs) = cfg.get("bootstrap").and_then(|b| b.get("packages")).and_then(|p| p.as_table()) else {
        return Ok(());
    };
    let supported = ["apt", "apk"];
    let bad: Vec<&String> = pkgs
        .keys()
        .filter(|k| !supported.contains(&k.as_str()))
        .collect();
    if !bad.is_empty() {
        return Err(format!("mise oci supports only apt/apk; unsupported: {bad:?}"));
    }
    Ok(())
}

Type guard

fn is_supported_oci_manager(name: &str) -> bool {
    matches!(name, "apt" | "apk")
}

Prevention

Keep a dedicated mise.toml for oci builds instead of reusing host configs that legitimately need brew/dnf
Add a CI lint step that fails when [bootstrap.packages] contains any key other than apt or apk
Review layered configs (global, directory, MISE_CONFIG_FILE) — a stray table anywhere triggers this at build time

When it happens

Trigger: mise.toml (or any layered config: ~/.config/mise/config.toml, MISE_CONFIG_FILE, directory-level mise.tomls) defines `[bootstrap.packages.brew]`, `[bootstrap.packages.dnf]`, `[bootstrap.packages.pacman]`, `[bootstrap.packages.yum]`, etc. with at least one non-empty request, and the user runs `mise oci build`.

Common situations: Reusing a mise.toml written for host setup where brew/dnf are valid; merging config from a teammate or a global CI config that adds system packages for non-container platforms; assuming `mise oci` supports every manager that plain `mise bootstrap` does.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/45b2f2951c689044. Report an issue: GitHub.