containerd

Overview

containerd is an upstream container runtime used by Kubernetes and other orchestrators. It provides the runtime layer that manages container lifecycle tasks such as image transfer and storage, container execution, supervision, and related host-side operations. Upstream documentation describes it as a daemon intended to be embedded into larger systems rather than used as a direct end-user application. (containerd.io)

For NiceOS, this package exists to provide a maintained RPM build of the upstream runtime so it can be integrated into distribution workflows, automation, and container stacks that expect containerd to be available as a system component. That distribution role is an inference from the upstream project’s documented use as a daemon and runtime layer; NiceOS maintainers should verify any distro-specific assumptions before relying on them. (containerd.io)

Purpose and typical use cases

Typical uses include:

• running container workloads under Kubernetes or another orchestrator;
• operating systems and platform services that need a container runtime daemon;
• local development and integration testing with tools that talk to containerd directly;
• packaging and CI/CD environments that need a consistent runtime component for build, test, or deployment workflows. (containerd.io)

Typical users include:

• platform and system administrators who install or manage the runtime on hosts;
• developers who integrate with the containerd API or use related client tooling;
• CI/CD maintainers who need repeatable container execution in build pipelines;
• security or compliance engineers who review packaging, provenance, and update impact around runtime components.

Upstream project

The upstream project is the containerd repository and its documentation site. The project describes containerd as an open and reliable container runtime and provides project documentation, getting-started material, and operational guidance. (github.com)

Useful upstream documentation entry points:

• project overview and docs landing page;
• getting started guide;
• main README and operational documentation;
• downloads page for official release artifacts and installation references. (containerd.io)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track upstream inputs;
• METADATA/ — repository/package metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when maintained for this package.

The exact file set may vary by package policy, but the structure above is the expected layout for this repository.

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 SOURCES manifest files and related metadata. This keeps the dist-git history smaller and makes it easier to review source provenance without checking large archives into Git.

When updating the package, maintainers should verify that the manifest entries still match the intended upstream source set and that the packaging rules continue to reference the correct inputs. The repository should be treated as the control plane for source selection and integrity tracking, not as the storage location for the full upstream tarball or archive content.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream changed build requirements, release engineering notes, or documented installation steps;
• whether any packaging patches still apply cleanly and still have a clear purpose;
• whether SPECS/ needs updates for build flags, file ownership, systemd integration, or subpackage layout;
• whether the SOURCES manifests need regeneration after upstream source changes;
• whether METADATA/ or SBOM/ content needs refresh to match the new source set;
• whether any local assumptions in the package remain valid for the target NiceOS branch.

Main risks to consider:

• unexpected build failures caused by upstream changes in Go, generated files, or packaging scripts;
• changes in upstream docs or build logic that make old patches obsolete;
• source mismatch if the manifest files are not regenerated after source updates;
• runtime behavior changes that affect orchestration or service startup on NiceOS systems.

Build and verification checklist

A practical maintainer checklist is:

• review upstream release notes and packaging guidance before starting the update;
• compare the new upstream source set with the existing SOURCES manifest entries;
• regenerate any manifest or metadata files that are derived from upstream inputs;
• inspect spec changes for build system, dependencies, service files, and installed paths;
• build the RPM in a clean environment;
• run the package’s available tests, if any are packaged or practical to run in the build environment;
• verify that installed files, permissions, and service units match expectations;
• confirm that the package starts and stops correctly in a test environment, if the package provides a daemon;
• check the resulting SRPM/RPM contents for unexpected additions or missing files;
• document any maintainer-facing changes that future updates will need to repeat.

References

• containerd documentation
• containerd getting started guide
• containerd main README
• containerd GitHub repository
• containerd downloads

Russian documentation

A Russian-language version of this document is available in README_RU.md.

Dist-git repository notes

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