check

Overview

check is a unit testing framework for C. It is used by projects that need a structured way to define and run tests, report failures, and keep tests isolated from the code under test.

In a Linux distribution, this package is typically useful as a development and build-time dependency for software that uses Check in its own test suite. It is not a runtime component for most end users; it mainly matters to maintainers, developers, and CI/CD systems that build or validate C software.

Purpose and typical use cases

Typical use cases include:

• running unit tests for C applications and libraries
• supporting package build tests and upstream test suites
• validating changes in CI/CD pipelines
• helping maintainers reproduce and debug test failures locally

Typical users include:

• C developers writing or maintaining test suites
• distribution packagers and RPM maintainers
• CI/CD maintainers running automated checks
• release engineers and integration engineers

If a downstream package depends on Check for its own tests, NiceOS maintainers should verify whether that dependency is needed only during build or also for other workflows.

Upstream project

Upstream project page: GitHub - libcheck/check

Project documentation: Check | Unit testing framework for C

The upstream project describes Check as a unit testing framework for C. Its documentation also includes installation notes and manual pages for the framework.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifest files used by the package
• METADATA/ — repository metadata maintained for dist-git workflows
• SBOM/ — software bill of materials data, when present or required by packaging policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the source content is referenced through files in SOURCES/, and integrity is tracked there with manifest files rather than by embedding large binary payloads in Git.

Source storage and integrity policy

The source policy for this package is to keep the repository lightweight and reviewable.

What this means in practice:

• upstream source archives stay outside the Git history
• SOURCES/ contains the metadata needed to fetch or verify sources
• manifest files in SOURCES/ are the place to check source integrity information
• maintainers should treat the manifest data as part of the packaging contract

Before relying on an update, verify that the source metadata still matches the intended upstream release and that any manifest regeneration was done intentionally.

NiceOS maintenance notes

Before updating the package, NiceOS maintainers should check the following:

• whether upstream changed build systems, test layout, or generated files
• whether SPECS/ needs changes for new configure options, build requirements, or test handling
• whether SOURCES/ manifests must be regenerated after refreshing upstream sources
• whether SBOM/ data needs to be updated to match the new packaged content
• whether any patches can be dropped, refreshed, or reordered
• whether the package still builds and tests cleanly with the distribution toolchain
• whether the update changes behavior that downstream packages rely on

Risks to consider:

• test suite failures caused by upstream changes in the framework or in generated test helpers
• packaging drift if source metadata and spec logic are updated out of sync
• accidental changes in build outputs when upstream regenerates autotools or CMake files
• downstream breakage if a dependency or build option changes unexpectedly

If any of these points are unclear from the update, NiceOS maintainers should verify them before shipping the change.

Build and verification checklist

A practical RPM maintainer checklist:

• review the upstream release notes and packaging-relevant changes
• compare the new source metadata against the current SOURCES/ manifests
• inspect patch series for obsolete or newly required patches
• confirm the spec file still matches the upstream build system
• rebuild the package in a clean mock or equivalent isolated environment
• run the package test suite if tests are enabled and available
• verify installed files, shared libraries, and development artifacts if the package ships them
• check that no unintended files were added to or removed from the RPM payload
• confirm that SBOM and repository metadata are still consistent with the package contents

If the package is used only as a build dependency, verify that runtime subpackages are still appropriate and not carrying unnecessary files.

References

• GitHub - libcheck/check
• Check | Unit testing framework for C
• Check | Installing Check
• Check 0.15.2: 1 Introduction

Russian documentation

• README_RU.md

Dist-git repository notes

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