docker

Overview

This repository packages Docker for NiceOS.

Docker Engine is an open source containerization technology for building and running applications in containers. In the Docker model, the daemon (dockerd) manages images, containers, networks, and volumes, while the docker CLI is the usual interface for users and automation. (docs.docker.com)

For a Linux distribution, this package typically exists to provide a packaged, reproducible, distribution-managed Docker installation instead of requiring users to install upstream binaries by hand. NiceOS maintainers should verify any distribution-specific integration details in the spec before relying on them.

Purpose and typical use cases

Typical use cases include:

• building and running containerized applications locally
• preparing development environments that behave consistently across machines
• running CI/CD jobs that need isolated build or test environments
• operating container-based workflows on developer workstations or servers
• using the Docker API from scripts or tooling that talks to the daemon directly (docs.docker.com)

Typical users include:

• developers who build and test container images
• administrators who manage container-enabled hosts
• CI/CD maintainers who need a stable container runtime on build workers
• security engineers who review container runtime and host integration choices
• desktop or workstation users who run containers for development and testing

Upstream project

The upstream documentation describes Docker as an open platform for developing, shipping, and running applications, centered around the Docker daemon, CLI, and API. The official documentation is the primary reference for user-facing behavior, installation guidance, and API details. (docs.docker.com)

If NiceOS maintainers need details about a specific Docker feature, command, or integration point, they should verify it against the official documentation for the relevant upstream release.

Dist-git repository contents

This dist-git repository is organized as follows:

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

Large upstream source archives are intentionally not stored directly in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. This keeps the repository small and makes updates easier to review.

Source storage and integrity policy

The source policy for this package is to keep large upstream archives out of Git and record the expected source inputs in SOURCES/ manifests.

Before an update, NiceOS maintainers should verify that:

• the manifest still points to the intended upstream source material
• any referenced tarballs or generated sources match the expected upstream release contents
• the spec file still applies cleanly to the new upstream source set
• any packaging patches still apply and remain necessary
• no repository metadata or SBOM artifact needs regeneration

Do not rely on a version-specific checksum in this README. The authoritative integrity data belongs in the repository-managed source manifests.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes for packaging-relevant changes
• changes to the Docker daemon, CLI, API, or packaging layout that might affect build or runtime behavior
• whether any downstream patches can be dropped, refreshed, or need a functional review
• whether generated files in SOURCES/, METADATA/, or SBOM/ need regeneration
• whether the spec still matches the current upstream documentation and build expectations

Risks to consider:

• daemon or service integration changes may affect system startup and administration
• API or CLI behavior changes may break automation or scripts
• packaging changes may affect file locations, dependencies, or post-install steps
• source or metadata regeneration mistakes can lead to a build that no longer matches the intended upstream input

If a detail is unclear in the package metadata, NiceOS maintainers should verify it before depending on it.

Build and verification checklist

Use this checklist when reviewing an RPM update:

• confirm the spec parses cleanly
• confirm the source manifests in SOURCES/ match the intended upstream input
• rebuild the package in a clean mock or equivalent build environment
• review build logs for new warnings, failures, or unexpected file ownership changes
• run the package test or smoke-test steps used by NiceOS, if any are defined
• verify that the installed commands, services, and configuration files match the spec intent
• check whether any generated metadata or SBOM output needs refreshing
• if applicable, perform a basic runtime test such as starting the service and running a minimal container workflow

References

• Docker Docs
• Docker Engine
• What is Docker?
• Docker Engine API
• Linux post-installation steps for Docker Engine

Russian documentation

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

Dist-git repository notes

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