CUnit

Overview

CUnit is a unit testing framework for C. It provides a lightweight test registry, suites, test cases, assertions, and several ways to run tests and report results. The upstream documentation describes it as a framework for writing, administering, and running unit tests in C, with automated and interactive interfaces. (cunit.sourceforge.net)

In a Linux distribution, this package exists to provide the CUnit library, headers, and related tooling needed by packages that build or run C unit tests. It is typically useful in development and packaging workflows rather than for end users who only consume desktop applications. If a local downstream change affects build flags, installed headers, or test runner behavior, NiceOS maintainers should verify that against the packaging files before relying on it. (cunit.sourceforge.net)

Purpose and typical use cases

Typical use cases include:

• writing unit tests for C libraries and applications
• running automated test suites during package builds or CI jobs
• using interactive test runners while developing or debugging C code
• collecting machine-readable test output for tooling that consumes XML or test logs (cunit.sourceforge.net)

Typical users are:

• library and application developers
• distribution packagers and RPM maintainers
• CI/CD maintainers who run test suites in build pipelines
• quality assurance and test engineers working with C projects
• security engineers who need reproducible test execution in analysis or hardening workflows

Upstream project

The upstream project is CUnit, a C unit testing framework hosted on SourceForge. The project documentation describes multiple interfaces, including automated, basic, console, and curses-based test runners. The upstream site and documentation are the primary references for package purpose and expected behavior. (cunit.sourceforge.net)

Upstream documentation:

• Home page: CUnit Home
• User and programmer documentation: CUnit Documentation
• Table of contents for the programmer guide: CUnit - Table of Contents

Dist-git repository contents

This dist-git repository contains the packaging inputs for the NiceOS RPM build:

• SPECS/ — the RPM spec file and related packaging logic
• SOURCES/ — manifest and metadata files used to track upstream source material and integrity information
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when present for the package or branch

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity metadata in SOURCES manifests so maintainers can verify what should be fetched or staged without committing bulky archives into Git. (cunit.sourceforge.net)

Source storage and integrity policy

For this package, source control in dist-git is metadata-driven rather than archive-driven:

• upstream source archives are not committed directly to the repository
• integrity is tracked through manifest files in SOURCES
• maintainers should compare the expected upstream source set against the manifests before building or updating
• if a packaging change requires regenerated metadata, the regenerated files should be reviewed together with the spec update

This repository does not document package-specific hash values in the README, and those values should be treated as build data rather than long-lived documentation.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream source layout, build system files, or installed paths changed
• whether the spec file still matches the upstream tarball contents and build steps
• whether any files in SOURCES need regeneration because the upstream release packaging changed
• whether SBOM/ material, if used for this package, needs to be refreshed
• whether the package still builds cleanly with the distribution toolchain and default RPM macros
• whether any patch in the spec is still needed or should be adjusted or dropped
• whether a change in upstream documentation affects installed examples, tests, or man pages

Risks to consider:

• upstream changes can alter test behavior or break package tests
• package updates can change library ABI or installed file layout; verify before pushing to stable branches
• build-system changes may require spec adjustments, especially if configure, CMake, or test execution steps move
• if the package is used by other builds in the distribution, check reverse build dependencies before publishing the update

If any of these points are uncertain, NiceOS maintainers should verify them against the spec, the source manifests, and upstream documentation before relying on the update.

Build and verification checklist

For RPM maintainers, a practical checklist is:

• review the upstream release notes and documentation for packaging-impacting changes
• compare the new upstream source material with the existing SOURCES manifests
• inspect the spec diff for changes in build flags, install paths, patching, or test execution
• rebuild in a clean mock or equivalent isolated environment
• run the package test suite if it is enabled in the spec
• verify that headers, library files, and documentation install where expected
• confirm that Provides, Requires, and subpackage split behavior still look correct
• check that any generated packaging metadata is updated consistently
• perform a local install or dependency test for packages that consume CUnit

References

• CUnit Home
• CUnit Documentation
• CUnit - Table of Contents
• CUnit - Introduction
• CUnit - Running Tests

Russian documentation

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

Dist-git repository notes

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