ding-libs

Overview

ding-libs is the upstream project for a small set of helper libraries used in the SSSD ecosystem. The upstream GitHub organization describes it as "DING is not GNU" helper libraries for SSSD and FreeIPA, and the SSSD project itself uses these building blocks in software that helps manage identity, authentication, and authorization on Linux systems. (github.com)

In a Linux distribution, this package exists to provide the shared library code and related utilities needed by other components that depend on the ding-libs API. NiceOS maintainers should verify the exact dependency chain in the distribution packaging before assuming a particular consumer.

Purpose and typical use cases

Typical use cases include:

• providing reusable helper code for SSSD-adjacent software;
• supporting packages that need common routines for working with the upstream Ding libraries;
• building and testing dependent packages that expect these libraries to be available at build time or run time.

Typical users are:

• distribution maintainers and RPM packagers;
• developers working on SSSD-related components;
• CI/CD maintainers who need reproducible builds of dependent packages;
• system administrators who install the packaged libraries as part of a larger identity-management stack.

Upstream project

Upstream source and project metadata are maintained in the SSSD GitHub organization. The canonical upstream repository for this package is the SSSD/ding-libs project. The repository is described upstream as helper libraries for SSSD and FreeIPA. (github.com)

Dist-git repository contents

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

• SPECS/ — RPM spec files and related packaging logic;
• SOURCES/ — source metadata and manifest files used to track imported upstream material;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials data, when present for the package.

The large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. Maintainers should treat the manifests as the authoritative record for imported source material.

Source storage and integrity policy

For this repository, source content is handled through package manifests rather than by committing large upstream archives directly into Git. That keeps the dist-git repository smaller and makes updates easier to review.

Before updating the package, NiceOS maintainers should verify that:

• the SOURCES/ manifest still matches the intended upstream source;
• any new upstream files are represented in the manifest data as expected;
• no local packaging patches depend on old upstream file layouts;
• the spec file still points to the correct source inputs;
• any SBOM data that is checked in remains consistent with the packaged payload.

If the upstream project changes its build system, file layout, or release process, maintainers should confirm whether the manifests or packaging rules need regeneration.

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream changed public APIs or library names used by dependent packages;
• whether packaging patches still apply cleanly;
• whether build scripts, autotools files, or generated helper files need regeneration;
• whether the license files and notices in the source set still match the packaged content;
• whether the SBOM content, if maintained for this package, needs a refresh.

Risks to consider:

• downstream build failures in packages that link against these libraries;
• accidental omission of a manifest update in SOURCES/;
• packaging drift if upstream reorganizes files or build tooling;
• stale generated files if the source tree is updated without rebuilding them.

Build and verification checklist

For RPM maintenance work, a practical checklist is:

1. Confirm the upstream source to be imported.
2. Update the SOURCES/ manifest data if the imported source set changes.
3. Review the spec file for version-independent assumptions.
4. Check whether any local patches still apply cleanly.
5. Rebuild the SRPM and RPMs in the standard build environment.
6. Run package tests or at least the project build and install checks available in the distro workflow.
7. Verify library sonames, installed paths, and generated metadata if the update could affect them.
8. Confirm that dependent packages still build against the updated package.
9. Review the resulting diff for unexpected file additions, removals, or regenerated content.

If the package uses generated sources or build-time code generation, verify that the generated files are reproducible and that the checked-in copies, if any, are still appropriate.

References

• SSSD organization on GitHub
• SSSD/ding-libs
• SSSD project documentation
• SSSD introduction

Russian documentation

• See README_RU.md

Dist-git repository notes

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