docker-compose

Overview

docker-compose is the package for Docker Compose, a tool for defining and running multi-container applications with Docker. In practice, it lets a project describe several services in one compose file and start them together with a single command. The upstream project is maintained by Docker and is documented as Compose for multi-container application workflows. (github.com)

For a Linux distribution, this package usually exists so users and automation can run Compose-based application stacks without managing the upstream build and packaging details themselves. It is commonly used as a command-line tool alongside Docker Engine and other container tooling. If a local deployment model or wrapper behavior is changed upstream, NiceOS maintainers should verify the package behavior before relying on it. (github.com)

Purpose and typical use cases

Typical use cases include:

• starting local development stacks made of multiple services
• running application environments defined in compose.yaml or similar files
• coordinating containers for testing, staging, and reproducible demos
• using Compose in CI/CD jobs that need to bring a stack up and tear it down
• managing small self-hosted service groups on a single host

Typical users include developers, system administrators, CI/CD maintainers, and platform engineers who need a repeatable way to launch related containers together. This package is not a full orchestration platform; it is the Compose CLI and related packaging expected by users who already work with Docker-based workflows. (github.com)

Upstream project

Upstream project: Docker Compose at the official docker/compose repository. The project describes itself as a tool to define and run multi-container applications with Docker. Official Docker documentation also frames Compose as a way to define running containers separately from the Dockerfile used to build images. (github.com)

When checking upstream changes, maintainers should pay attention to release notes, CLI behavior changes, plugin installation conventions, and any updates to the Compose file specification that may affect packaged scripts or documentation. If a specific behavior is important to NiceOS packaging, verify it against the upstream documentation before changing the spec file. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifests used by the build system
• METADATA/ — package metadata used by the dist-git workflow
• SBOM/ — software bill of materials data, when present for this package

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, so the repository stays small and reviewable while still recording which upstream source material belongs to the package. The exact manifest format may vary by package; maintainers should inspect the files in SOURCES/ rather than assuming a fixed layout. (github.com)

Source storage and integrity policy

The repository keeps source control metadata and build instructions, not the full upstream payload. This means:

• upstream archives are fetched or reconstructed by the packaging workflow, not committed as large blobs
• integrity is recorded through manifest data in SOURCES/
• reviewers should check that the manifest matches the intended upstream source and that any repackaging or vendoring rules are still correct

Before an update, NiceOS maintainers should verify that the source manifest still points to the intended upstream content and that any packaging-side adjustments remain valid. If upstream changes the release structure or renames files, the source metadata may need regeneration. (github.com)

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream changed the CLI, subcommands, or default behavior used by packaged scripts
• whether the spec file still matches the expected upstream build or install layout
• whether files in SOURCES/ need to be regenerated because the upstream source selection changed
• whether SBOM/ or METADATA/ needs a refresh if NiceOS packaging policy requires it
• whether downstream patches still apply cleanly and are still needed
• whether any change affects plugin paths, completion files, or wrapper scripts used by users
• whether documentation in the package still reflects the current upstream usage model

Risks to consider:

• upstream may change how Compose is distributed or invoked
• packaging assumptions about file layout may break if upstream reorganizes the repository
• updates may require review of any spec-file conditionals or helper scripts
• if NiceOS carries local patches, those patches may need to be simplified or dropped after an upstream update

If any of these points are uncertain, NiceOS maintainers should verify them against the upstream repository and official documentation before publishing the update. (github.com)

Build and verification checklist

For an RPM update, a maintainer should usually check:

• spec file parses cleanly
• source manifests in SOURCES/ match the intended upstream input
• build succeeds in a clean mock or comparable build environment
• installed files match the package layout expected by the spec
• runtime help output is sensible after installation
• any shell completions, man pages, or wrapper scripts still work if packaged
• optional tests or smoke checks pass if they are available in the packaging workflow
• the package does not accidentally depend on files outside the intended build inputs
• file ownership and permissions are correct
• no generated metadata was committed unless it is intentionally maintained in the repository

A minimal post-build check is usually to run the Compose command help and, if feasible, a small stack definition in an isolated environment. The exact verification step should follow NiceOS packaging policy and the behavior expected by the upstream release being packaged. (github.com)

References

• Docker Compose upstream repository
• What is Docker Compose? — Docker Docs

Russian documentation

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

Dist-git repository notes

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