containers-common

Overview

containers-common packages shared files and helper code used across the Containers project ecosystem. The upstream repository describes it as a place for common files and common Go code used by other repositories in the containers organization, and notes that the project has moved to container-libs for new development. For NiceOS, this package typically exists to provide reusable container-management assets without duplicating them across multiple packages. (github.com)

Purpose and typical use cases

This package is generally useful when a system needs shared container-related configuration, helper scripts, or library code that is consumed by other container tools. Typical users include:

• distribution maintainers who package and update shared container components;
• administrators who rely on container tooling shipped by the distribution;
• developers working on container runtimes, image tools, or related automation;
• CI/CD maintainers who need consistent container behavior in build and test jobs;
• security engineers who review container-related helper code and generated policy files.

Where the exact downstream use in NiceOS is not obvious from the package metadata alone, maintainers should verify the actual consumers before relying on that assumption. (github.com)

Upstream project

Upstream lives in the containers GitHub organization. The repository containers/common is the source of the shared material, and the upstream README says that new development happens in containers/container-libs. That means NiceOS maintainers should check the current upstream location and packaging expectations before making larger update decisions. (github.com)

Dist-git repository contents

This dist-git repository is organized in the usual RPM package layout:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to record what upstream content is expected;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials data, when maintained for the package.

Large upstream source archives are intentionally not stored directly in this Git repository. Instead, the repository keeps the packaging metadata needed to reconstruct and verify the source set during builds. (github.com)

Source storage and integrity policy

NiceOS tracks source integrity through the manifest files stored in SOURCES/. The exact filenames and manifest format may vary by packaging workflow, but the intent is stable: the Git repository records what should be fetched and verified, while large upstream archives remain outside Git history. Maintain by checking that the manifests match the intended upstream release artifacts and that the spec file references them consistently. Do not rely on this repository as the sole storage location for upstream sources. (github.com)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should verify:

• whether upstream development still happens in containers/common or has moved to the newer container-libs location;
• whether any packaging logic in SPECS/ depends on files that changed upstream;
• whether SOURCES/ needs to be regenerated after upstream changes;
• whether SBOM/ needs to be refreshed if NiceOS tracks bill-of-materials data for this package;
• whether any downstream patches, file lists, or install paths still apply cleanly;
• whether the update changes the set of shared files consumed by other container packages.

Risks to consider include silent drift between the spec file and the source manifest, accidental omission of a shared file used elsewhere in the distribution, and mismatches between upstream layout changes and downstream packaging expectations. If a dependency or consumer relationship is not documented in the repository, verify it before changing packaging behavior. (github.com)

Build and verification checklist

For RPM maintenance work, a practical checklist is:

• review the upstream repository for layout changes and release notes;
• confirm that the files listed in SOURCES/ still match the intended upstream input;
• verify that the spec file installs the expected files and no unintended extras;
• check for removed or renamed scripts, generated files, or documentation;
• rebuild the SRPM and binary RPMs in the NiceOS build environment;
• run the package test or sanity checks available in the spec or upstream tree;
• inspect the resulting file list, ownership, permissions, and payload paths;
• confirm that any SBOM/ data and repository metadata still reflect the updated source set;
• review the update for downstream impact on other container-related packages.

If the package pulls in generated files or manifests from upstream, regenerate them as part of the update rather than editing them by hand, unless the packaging policy says otherwise. (github.com)

References

• containers organization
• containers/common

Russian documentation

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

Dist-git repository notes

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