dejagnu

Overview

DejaGnu is a GNU testing framework used to run test suites for other programs through a common test-driver interface. It is built around Expect and Tcl, and it is commonly used where a project needs one test harness that can drive interactive or batch-oriented tests across different targets. (gnu.org)

In a Linux distribution, this package is typically useful as a test framework dependency for projects that ship or run DejaGnu-based test suites. NiceOS maintainers should verify the exact relationship for each dependent package before relying on it.

Purpose and typical use cases

Typical uses include:

• running upstream test suites during package builds or in a separate test environment;
• testing cross-toolchain and target-specific software;
• providing a consistent harness for projects that need to report test results in a standard way;
• supporting maintainers who need to repeat or debug automated tests with runtest.

Common users are:

• RPM and distribution maintainers;
• developers who maintain upstream test suites;
• CI/CD maintainers who need repeatable automated testing;
• build and release engineers working with target-dependent software.

Upstream project

Upstream documentation describes DejaGnu as a framework for testing other programs and as a library of Tcl procedures for writing test harnesses. The main test driver is runtest, and GNU Automake has built-in support for DejaGnu-based test targets. (gnu.org)

Official upstream resources:

• project home page and manual from GNU;
• manual sections covering make check, runtest, and test harness setup. (gnu.org)

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 to track upstream source integrity;
• METADATA/ — repository metadata used by packaging workflows;
• SBOM/ — software bill of materials data when present.

The upstream source archive itself is intentionally not stored in this Git repository. Instead, integrity is tracked through manifest files in SOURCES/. Do not expect large upstream tarballs to appear in the dist-git tree.

Source storage and integrity policy

NiceOS keeps the repository small and reviewable by storing source references and integrity metadata, not the full upstream archive.

What to check when updating sources:

• that the manifest in SOURCES/ still matches the upstream source being packaged;
• that any source reference or integrity metadata was regenerated intentionally;
• that the spec file still points to the intended upstream release and build inputs;
• that no extra files were added to the repository by mistake.

If a maintainer changes the upstream source layout or packaging method, they should verify whether the source manifest format, SBOM data, or other generated metadata needs regeneration.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream documentation changed the expected way to build or run tests;
• whether the spec file needs packaging adjustments for new build-time requirements;
• whether SOURCES/ manifests need to be regenerated;
• whether SBOM/ or other metadata needs refresh if the repository policy requires it;
• whether the update affects test execution, especially if the package is used by other test-driven builds.

Risks to consider:

• test harness behavior may change even when the package name does not;
• upstream changes may affect runtest-based workflows or test environment setup;
• packaging metadata can drift from the actual upstream source if the manifests are not refreshed carefully.

If a detail is unclear, NiceOS maintainers should verify it against upstream sources before depending on it.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• review the spec file for source, build, and test changes;
• confirm that the SOURCES/ manifest matches the intended upstream content;
• rebuild in a clean environment;
• run the package test suite if one is available in the build process;
• inspect build logs for missing test tools or environment assumptions;
• verify that generated packaging metadata is consistent with the updated source;
• check that no unintended repository files changed outside the expected packaging updates.

For projects that use DejaGnu directly, upstream documents make check as the usual entry point, with runtest used to drive or repeat tests. (gnu.org)

References

• GNU DejaGnu manual: What is DejaGnu?
• GNU DejaGnu manual: Running make check
• GNU DejaGnu manual: runtest
• GNU DejaGnu manual: Adding a new tool
• GNU DejaGnu project page

Russian documentation

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

Dist-git repository notes

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