dotconf

Overview

dotconf is a C library for parsing configuration files written in the upstream project's dot.conf format. In practice, it gives applications a reusable parser instead of making each project implement its own configuration reader. The upstream repository describes it as a configuration file parser and includes examples and documentation in the source tree. (github.com)

For NiceOS, this package exists to provide a packaged library that other software can link against when it needs to read structured configuration files. Typical users are application developers, distribution maintainers, and integrators who need consistent configuration parsing in build or runtime environments.

Purpose and typical use cases

Common use cases include:

• linking an application against a shared library for configuration parsing;
• shipping software that expects to read dot.conf-style configuration files;
• building tools or services that need a small, reusable config parser instead of ad hoc file handling.

Typical users include:

• developers embedding configuration parsing into their software;
• RPM and distro maintainers packaging software that depends on the library;
• CI/CD maintainers validating that dependent builds still compile and run;
• security or quality engineers reviewing parser behavior as part of update testing.

Upstream project

Upstream project page: williamh/dotconf

The upstream repository identifies dotconf as a configuration file parser and contains source code, documentation, and example files. It is licensed upstream under LGPL-2.1. NiceOS maintainers should verify any licensing or packaging details against the repository contents before making update decisions. (github.com)

Dist-git repository contents

This NiceOS dist-git repository is organized in the usual RPM packaging layout:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used by the build system;
• METADATA/ — package metadata used by the dist-git workflow;
• SBOM/ — software bill of materials material, when present.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in SOURCES manifests and related metadata. That allows the dist-git history to stay small and keeps the repository focused on packaging data rather than mirrored upstream tarballs.

NiceOS maintainers should treat the manifest files as part of update review. When the upstream source changes, verify that the manifest is regenerated through the expected packaging workflow and that the recorded source reference still matches the intended upstream release or commit. Do not rely on local assumptions about archive contents.

NiceOS maintenance notes

Before updating this package, check at least the following:

• whether upstream changed the build system or required tooling;
• whether the spec file still matches the current upstream layout;
• whether any generated packaging files need refresh, such as metadata, manifests, or SBOM material;
• whether the upstream documentation or example files changed in a way that affects tests or downstream consumers;
• whether any build-time or runtime dependencies in the spec need adjustment.

Risks to consider:

• parser behavior changes may affect applications that rely on existing config syntax;
• build-system changes may require spec updates or regenerated helper files;
• documentation or examples may lag behind code changes, so verify the actual source tree rather than assuming compatibility.

If any detail is unclear from the package sources, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

For RPM maintenance, a practical update check usually includes:

• confirm the spec file still builds with the current toolchain;
• review upstream release notes, commit messages, and repository changes;
• regenerate any packaging metadata that the workflow expects;
• ensure the source manifest in SOURCES matches the intended upstream source set;
• run the package build in a clean environment;
• run any available upstream tests or at least the relevant library test suite;
• verify that installed headers, libraries, and documentation land in the expected subpackages;
• check for ABI-sensitive changes if dependent packages consume the shared library;
• inspect the resulting RPMs for file ownership, dependencies, and packaging warnings.

References

• Upstream repository

Russian documentation

See README_RU.md.

Dist-git repository notes

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