crun

Overview

crun is an OCI container runtime written in C. In a Linux distribution, packages like this provide the runtime binary that container engines and higher-level tooling can call when they need to create and manage containers according to the OCI runtime model. The upstream project describes crun as a fast, lightweight runtime and library for running containers. (github.com)

For NiceOS maintainers, the main value of this package is that it supplies a container runtime implementation that can be selected by container stacks which support OCI-compatible runtimes. If a local deployment uses crun in a different role, maintainers should verify the exact integration in that environment. (github.com)

Purpose and typical use cases

Typical use cases include:

• running OCI containers from container engines and orchestration components,
• providing an alternative runtime implementation for systems that support runtime selection,
• packaging a runtime that can also be used as a library by upstream consumers that integrate with crun directly, if their stack expects that model. (github.com)

Typical users include:

• system administrators managing container hosts,
• platform and release engineers maintaining containerized services,
• developers working on container tooling,
• CI/CD maintainers who need a predictable container runtime in build and test environments,
• security or hardening engineers who need to review runtime behavior as part of a container stack.

This package does not claim any distribution-wide default role here; its practical use depends on the surrounding container stack.

Upstream project

Upstream project: containers/crun

The upstream repository contains the runtime source, build system, documentation, tests, and related project files. The project documents conformance with the OCI Runtime Specification. (github.com)

Dist-git repository contents

This NiceOS dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging metadata.
• SOURCES/ — source manifest files and other packaging-side source metadata.
• METADATA/ — repository metadata used by the dist-git workflow.
• SBOM/ — software bill of materials artifacts, if present for this package branch.

The exact file set may change over time, but the repository should remain focused on packaging inputs rather than on large upstream source payloads.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in manifest files under SOURCES/.

For maintainers, this means:

• check that the manifest references still match the intended upstream source material,
• update or regenerate the manifest files when the upstream source set changes,
• avoid assuming that the Git history contains the full upstream tarball or vendor payload,
• verify that any packaging-side source list remains complete after upstream changes.

The repository should be treated as packaging metadata plus integrity tracking, not as a mirror of the full upstream release archive.

NiceOS maintenance notes

Before updating the package, NiceOS maintainers should check:

• whether upstream changed the build system, generated files, or install paths,
• whether the packaging spec still matches upstream build and install behavior,
• whether any SOURCES/ manifest files need regeneration because upstream files changed,
• whether the SBOM data, if maintained for this branch, needs refresh,
• whether the package still builds cleanly on supported NiceOS buildroots,
• whether runtime behavior changes affect container engine integration, logging, or default paths in the target environment.

Maintainership risks to consider:

• source manifest drift if upstream source inputs change,
• packaging regressions from renamed, added, or removed upstream files,
• behavior changes in container runtime semantics that affect dependent tooling,
• incomplete assumption of feature support unless confirmed in upstream documentation or local build results.

If a detail is uncertain, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

A practical RPM maintainer checklist:

• confirm the upstream source set matches the manifests in SOURCES/,
• inspect the spec for patches that may need rebasing or removal,
• review %build, %install, and %check behavior for upstream changes,
• rebuild in a clean mock or equivalent buildroot,
• verify that the installed files match the expected runtime layout,
• run package tests or upstream checks when available and suitable for the build environment,
• review the resulting RPM metadata for unintended new dependencies or missing file ownership,
• confirm that any generated documentation or auxiliary files are still produced correctly,
• if the package is used by container tooling in your environment, do a local runtime smoke test after the update.

References

• containers/crun
• Open Container Initiative Runtime Specification

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

• Package repository: rpms/crun
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.