c-ares

Overview

c-ares is a C library for asynchronous DNS requests and related name-resolution work. Upstream describes it as a modern DNS resolver library intended for applications that need DNS lookups without blocking or that need to process multiple queries in parallel. (github.com)

In a Linux distribution, this package typically exists so other software can link against a maintained resolver library instead of reimplementing DNS handling on its own. That makes it useful infrastructure for networked applications, daemons, and tools that need resolver functionality. NiceOS maintainers should verify the exact downstream dependency set before making assumptions about where it is used.

Purpose and typical use cases

Typical uses for c-ares include:

• asynchronous DNS lookups in network applications;
• resolver support in event-driven software;
• parallel or non-blocking hostname resolution;
• library-level DNS functions for applications that do not want to rely only on blocking system resolver calls. (github.com)

Typical users include:

• application developers integrating DNS resolution into C or C-based software;
• distribution and package maintainers who need a reliable resolver library in the build root;
• CI/CD maintainers validating build and test behavior across toolchain changes;
• system and network administrators who inspect package behavior and dependencies in their environment;
• security engineers reviewing how a networking component is packaged and updated.

Upstream project

Upstream project information is available from the c-ares website and source repository. The project documentation describes installed man pages and library APIs, and the upstream repository contains the code and release archives. (github.com)

If you need a deeper functional overview for a specific update, check upstream release notes, API documentation, and build instructions before changing the package. NiceOS maintainers should verify any release-specific behavior directly in upstream sources.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source manifests and other metadata used to describe the imported upstream source set.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials data, when present for the package.

The repository is meant to carry packaging metadata, not the full upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the source state is tracked through manifest files in SOURCES/.

For maintainers, this means the important checks are about consistency and provenance of the imported source set, not about committing the archive itself. Before updating the package, verify that:

• the SOURCES/ manifest points to the intended upstream source material;
• the spec file matches the new source layout if upstream changed file names, install paths, or build tooling;
• any generated packaging metadata remains consistent after source refresh;
• the imported source set is complete and matches the expected upstream release or tagged snapshot.

NiceOS maintenance notes

Before updating c-ares in NiceOS, check the following:

• review upstream release notes, changelog entries, and API changes for anything that may affect dependent packages;
• compare the new upstream source layout with the current spec file, patches, and build flags;
• verify whether any generated files need to be refreshed, such as documentation, bundled man pages, or build-system metadata used by the package;
• check whether downstream patches still apply cleanly and whether they should be dropped, rebased, or kept;
• confirm that the source manifest in SOURCES/ is updated consistently with the new imported source set;
• review whether the update could change library behavior for dependent packages, especially consumers of DNS resolution logic.

Risks to consider:

• upstream build-system changes may require spec changes;
• API or ABI changes may affect dependent packages;
• documentation or generated output may drift from the packaged source if regeneration steps are missed;
• changes in test behavior may require temporary exclusions or test adjustments, but only after verifying the reason.

Build and verification checklist

For RPM maintainers, a typical update review should include:

• confirm the source import matches the intended upstream release or tag;
• inspect SOURCES/ for the updated source manifest and related metadata;
• run a clean build in the target NiceOS build environment;
• check that %prep, %build, %install, and %check complete as expected;
• verify that shared libraries, headers, and documentation land in the expected subpackages;
• compare the generated build output against the previous package for unexpected file additions or removals;
• run dependency and reverse-dependency checks for packages that link to c-ares;
• inspect the resulting RPM metadata for packaging regressions;
• review the installed man pages and library files if the package ships them;
• if tests are available in the packaging workflow, run them and investigate any failures before shipping.

References

• c-ares website
• c-ares documentation
• c-ares source repository

Russian documentation

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

Dist-git repository notes

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