diffutils

Overview

diffutils provides the standard GNU file comparison tools used to inspect differences between files and directories. The upstream project includes diff, diff3, sdiff, cmp, and related documentation. In a Linux distribution, this package is useful anywhere maintainers or users need to compare text files, review changes, or generate comparison output for patching and merge workflows. (gnu.org)

Typical users include:

• package maintainers who review spec or config changes,
• developers who compare source trees or generated files,
• CI/CD maintainers who check build artifacts or release diffs,
• system administrators who compare configuration snapshots,
• security engineers who inspect file changes during audits or incident response.

Purpose and typical use cases

The package exists to provide reliable, scriptable comparison commands that are part of the normal Unix and GNU toolchain. Common use cases include:

• comparing two files line by line,
• comparing directory trees,
• creating and reviewing patch-style output,
• merging changes from a common ancestor with diff3,
• performing side-by-side comparisons with sdiff,
• checking whether two files are identical with cmp.

These tools are often used during packaging, code review, release preparation, and configuration management. The exact workflow depends on the surrounding system; NiceOS maintainers should verify any distribution-specific conventions before relying on them.

Upstream project

Upstream is the GNU Diffutils project from the GNU Project / Free Software Foundation. Its manual documents the comparison and merging tools shipped by the project and is the primary reference for command behavior. (gnu.org)

Useful upstream documentation:

• project page,
• user manual,
• command-specific manual pages in the online documentation.

Dist-git repository contents

This dist-git repository contains the packaging metadata for NiceOS, not the full upstream source tree.

Expected top-level content:

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

Large upstream source archives are intentionally not stored in this Git repository. The repository keeps only the packaging files and the integrity metadata needed to fetch and verify the sources elsewhere.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/. Those manifests record what upstream content the package should use, while the actual source archive is stored outside this Git repository.

For maintainers, this means:

• do not add large upstream tarballs or generated archives to Git,
• update the manifest and packaging metadata together when upstream sources change,
• make sure the referenced upstream input still matches the packaging intent,
• verify that the manifest and spec file stay in sync after any source refresh.

If the package uses additional generated source files, NiceOS maintainers should confirm whether those files are tracked in SOURCES/ or regenerated from upstream during the build.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes and changelog entries that affect build or runtime behavior,
• whether the spec file needs a dependency, macro, or path adjustment,
• whether any packaging patches still apply cleanly,
• whether man pages, info pages, or other generated documentation need regeneration,
• whether tests, examples, or locale data changed in ways that affect the build,
• whether the SBOM data should be refreshed,
• whether the source manifest in SOURCES/ needs to be replaced or regenerated.

Risks to consider:

• comparison tools are often relied on in scripts, so even small behavior changes can be visible,
• command-line output changes may affect test baselines or automation,
• build-time documentation generation may drift from upstream if the toolchain changes,
• file layout changes can break packaging assumptions.

If any of these points are unclear for a specific update, NiceOS maintainers should verify them against upstream documentation and the local packaging rules before proceeding.

Build and verification checklist

For an RPM update, a practical maintainer checklist is:

• confirm that the upstream source reference in SOURCES/ is the intended one,
• review the spec file for versioned paths, patches, and build flags,
• run a clean mock or equivalent isolated build,
• check that the package installs the expected binaries and documentation,
• verify that generated man pages or docs are current if the build regenerates them,
• run the package test suite if one is enabled in the spec,
• inspect build logs for warnings, missing files, or install-path mismatches,
• compare the resulting file list against the previous build for unexpected changes,
• confirm that SBOM or metadata files still reflect the packaged content,
• perform a basic runtime check such as invoking diff --version or a simple file comparison.

References

• GNU Diffutils project page
• GNU Diffutils manual
• GNU Diffutils command documentation

Russian documentation

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

Dist-git repository notes

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