cjson

Overview

cJSON is a small JSON library for C. Upstream describes it as an ultralightweight JSON parser in ANSI C. It is used when a project needs to read, write, or inspect JSON data without bringing in a large dependency stack. (github.com)

In a Linux distribution, this package typically exists to provide the library and development files needed by other software that links against cJSON. NiceOS maintainers should verify the exact subpackages and install paths in the spec file for this repository.

Purpose and typical use cases

Typical use cases include:

• parsing JSON configuration or API responses in C applications;
• generating JSON output from services, tools, or tests;
• providing a lightweight JSON dependency for packages that need C-level JSON handling;
• building software that expects the cJSON headers and library at compile time.

Typical users are:

• application developers writing C code;
• distribution maintainers packaging software that depends on cJSON;
• CI/CD maintainers validating builds and ABI-sensitive packaging changes;
• security or release engineers checking source integrity and update impact.

Upstream project

Upstream is the DaveGamble/cJSON project on GitHub. The repository README describes the project, usage notes, and build entry points. Upstream also publishes release information and documentation in the repository. (github.com)

If you need to confirm build system behavior, public documentation in the upstream repository is the first place to check. For package updates, NiceOS maintainers should verify whether the upstream build instructions, file layout, or supported build systems changed.

Dist-git repository contents

This dist-git repository is organized in the standard RPM package layout:

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

The repository does not store large upstream source archives directly. Instead, source integrity is tracked through manifest files in SOURCES/. NiceOS maintainers should use those manifests and the spec file together when reviewing or updating the package.

Source storage and integrity policy

The source policy for this repository is to keep large upstream source archives out of Git. Only the metadata needed to identify and verify the sources is kept under version control.

Before accepting an update, check that:

• the SOURCES/ manifest still matches the expected upstream source set;
• the spec file references the intended source material;
• any added or removed auxiliary files are deliberate;
• no local patch depends on an old upstream file layout.

Do not rely on stored archive names or checksums in this README; they are intentionally omitted so this document stays stable across updates.

NiceOS maintenance notes

Before updating the package, NiceOS maintainers should review:

• upstream release notes and changelog entries that affect build behavior or API expectations;
• whether the packaging spec needs patch refreshes or source list changes;
• whether SOURCES/ manifests need regeneration after a source change;
• whether SBOM/ metadata, if maintained for this package, needs to be refreshed;
• whether downstream consumers depend on headers, library names, or build flags that could change.

Practical risks to consider:

• upstream build scripts may change, especially for CMake or alternative build paths;
• tests may need environment-specific adjustments in the build system;
• local patches may become obsolete or conflict with upstream changes;
• file installation paths or exported targets may shift and break dependent packages.

If any of these are uncertain, NiceOS maintainers should verify them before merging the update.

Build and verification checklist

A maintainer-oriented checklist for RPM updates:

• confirm the upstream source reference in SOURCES/ is the intended one;
• review the spec diff for new patches, removed patches, or changed build flags;
• rebuild the package in a clean environment;
• run package tests if the spec enables them, or verify that tests are intentionally disabled;
• inspect the resulting file list for header, library, and documentation changes;
• check for ABI-impacting changes if dependent packages are sensitive to library behavior;
• verify that %files entries still match installed paths;
• confirm that any generated metadata files are updated consistently.

For dependent-package validation, a simple compile-and-link check is often useful, but NiceOS maintainers should adapt it to the packaging policy in use.

References

• Upstream repository
• Upstream releases
• Upstream changelog

Russian documentation

See README_RU.md.

Dist-git repository notes

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