cppunit

Overview

CppUnit is a C++ unit testing framework. Upstream describes it as a C++ port of JUnit, with test output available in text and XML forms for automated and supervised test runs. In a Linux distribution, this package exists so that other software can build and run test suites against a known, packaged CppUnit installation.

This repository is the NiceOS RPM dist-git source of truth for the package. It is meant for maintainers, packagers, and users who need to understand how the package is assembled and what should be checked before updates.

Purpose and typical use cases

Typical use cases include:

• building and running C++ unit tests during software development
• adding test infrastructure to packaged upstream projects
• running distribution QA or CI jobs that depend on CppUnit
• keeping a consistent system package available for projects that still use CppUnit APIs

Typical users include:

• application and library developers
• RPM and distribution maintainers
• CI/CD maintainers
• QA and test infrastructure engineers

Upstream project

Upstream project page:

• CppUnit on SourceForge: see the References section

The upstream project is old and its public project information is limited. If a maintainer needs details about current development status, build requirements, or release expectations, verify them against the upstream project pages before relying on them.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source manifests and integrity metadata used by the RPM build
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when present in the repository

The repository intentionally does not store large upstream source archives in Git. Instead, source references and integrity metadata are kept in SOURCES/ so that the package can be reviewed and rebuilt without committing bulky upstream archives to version control.

Source storage and integrity policy

NiceOS keeps upstream source integrity tracking in the SOURCES/ manifests. Those manifests are what maintainers should check when reviewing or updating the package.

Practical implications:

• do not expect the upstream tarball itself to be committed here
• review the source manifest entries when sources change
• confirm that the spec file still matches the source layout and packaging expectations
• if the package uses generated files, verify whether those files need to be refreshed as part of the update

This repository does not print concrete digest values in the README. Maintainers should rely on the tracked manifest data in SOURCES/ and the package build process.

NiceOS maintenance notes

Before updating cppunit, NiceOS maintainers should check:

• whether the upstream source layout changed
• whether the spec file still applies cleanly
• whether any patch series still applies or should be refreshed
• whether build-time tests, examples, or documentation need regeneration
• whether the package still builds with the target toolchain used by NiceOS
• whether the update changes packaging assumptions, such as installed paths or generated headers

If the upstream release changes generated build artifacts or build scripts, maintainers may need to regenerate SOURCES/ metadata or refresh spec-file patching. If the project is unusually quiet upstream, verify that any update is still appropriate for distribution policy before importing it.

A practical review sequence is:

1. inspect the spec diff
2. compare the new upstream source tree with the previous one
3. update or drop patches as needed
4. check that manifests in SOURCES/ are updated correctly
5. rebuild in a clean mock or equivalent build environment
6. run the package test suite, if available
7. inspect the resulting RPM contents for unexpected file additions or removals

Build and verification checklist

For RPM maintainers, a normal update review should include:

• rpmbuild or mock build succeeds in a clean environment
• spec file parses without warnings that indicate packaging mistakes
• source manifest entries in SOURCES/ match the imported source material
• patches apply cleanly, or are removed if no longer needed
• any bundled generated files are handled according to distribution policy
• license files and package metadata still match the packaged contents
• installed headers, libraries, and documentation land in the expected paths
• automated tests run, if the package or dependent build system provides them
• the resulting build does not introduce unexpected ABI or packaging changes

If you are updating a downstream consumer at the same time, verify that it still builds against the packaged CppUnit headers and libraries after the update.

References

• CppUnit project page on SourceForge
• CppUnit files page on SourceForge

Russian documentation

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

Dist-git repository notes

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