cpio

Overview

cpio is the GNU utility for creating and extracting cpio archives, and it can also work with tar archives in compatible modes. In practice, it is used to move file trees between directories, archive filesystem content, and restore archived data when a cpio-formatted archive is required. GNU cpio reads file lists from standard input in its archive-creation modes, which makes it convenient in scripted workflows and recovery tasks. (gnu.org)

In NiceOS, this package exists to provide the upstream cpio command-line tool as a distributable RPM. That makes it available for system maintenance, build tooling, archival workflows, and any software that expects a standard cpio implementation. NiceOS maintainers should verify any distro-specific usage before relying on it for a particular workflow.

Purpose and typical use cases

Typical uses of cpio include:

• creating an archive from a file list supplied by find, ls, or another tool;
• extracting a cpio archive into a filesystem tree;
• copying files between directory trees without creating a temporary archive first;
• handling archive content in shell scripts, initramfs or rescue-style workflows, and maintenance jobs;
• working with legacy archive formats that still appear in administrative environments. (gnu.org)

Typical users include:

• system administrators who need archive and restore tooling;
• developers and build engineers who integrate cpio into packaging or release scripts;
• CI/CD maintainers who need deterministic file-transfer or archival steps in pipelines;
• security engineers and incident responders who may inspect or unpack archive content during recovery work.

Upstream project

The upstream project is GNU cpio, part of the GNU Project. The official documentation describes it as a tool for copying files into or out of cpio or tar archives, and the project page points to GNU-hosted downloads and the Savannah project area for news and patches. (gnu.org)

Canonical references:

• GNU Cpio project page: https://www.gnu.org/software/cpio/cpio.html
• GNU Cpio manual: https://www.gnu.org/s/cpio/manual/cpio.html

Dist-git repository contents

This dist-git repository is structured as follows:

• SPECS/ — RPM spec files and package policy metadata;
• SOURCES/ — source manifests and other tracked source metadata used by the packaging workflow;
• METADATA/ — repository metadata used by the packaging infrastructure;
• SBOM/ — software bill of materials artifacts, when present.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps integrity metadata in SOURCES/ manifests so that maintainers can verify the expected upstream inputs without versioning the full archive content in Git.

Source storage and integrity policy

NiceOS keeps the packaging sources in a form that is stable for dist-git and review workflows:

• upstream source archives are fetched or referenced outside the Git history rather than committed here;
• SOURCES/ contains manifest data used to track the expected source inputs;
• repository review should focus on whether the manifest, spec file, and packaging metadata still describe the upstream source correctly.

Do not assume that the presence of a manifest alone is enough for a package update. NiceOS maintainers should still verify that the upstream source being packaged is the intended one and that the packaging rules match it.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release changes the command-line behavior, archive format handling, or default extraction behavior in ways that matter to downstream users;
• whether any spec-file patches still apply cleanly and are still required;
• whether SOURCES/ manifests and any related metadata need regeneration;
• whether SBOM/ content, if tracked for this package, needs to be refreshed;
• whether file lists, installed paths, or packaging macros need adjustment;
• whether the update changes documentation or test expectations that downstream scripts depend on.

Practical risks to consider:

• archive-format changes can affect interoperability with older scripts or recovery procedures;
• behavior changes around path handling, extraction, or ownership can break automation;
• packaging metadata drift can make review harder if manifests and spec files are not kept aligned.

If any of these points are uncertain for a particular upstream drop, NiceOS maintainers should verify them before relying on the update.

Build and verification checklist

For RPM maintenance, a reasonable update checklist is:

1. Confirm the upstream source and version being packaged.
2. Review the spec file for changed patches, build requirements, or install paths.
3. Check that SOURCES/ manifests match the intended upstream input.
4. Regenerate any metadata that the repository policy expects, including SBOM artifacts if used.
5. Build the SRPM and the binary RPMs in a clean environment.
6. Inspect the build log for new warnings, failures, or dependency surprises.
7. Run package tests or basic smoke checks if available.
8. Verify that the installed files and generated documentation match expectations.
9. Confirm that archive creation and extraction still work for the packaging scenarios NiceOS cares about.
10. Review the resulting RPM payload and metadata before submitting the update.

References

• GNU Cpio project page: https://www.gnu.org/software/cpio/cpio.html
• GNU Cpio manual: https://www.gnu.org/s/cpio/manual/cpio.html
• GNU Cpio archive documentation: https://www.gnu.org/software/cpio/manual/html_node/cpio.html

Russian documentation

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

Dist-git repository notes

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