apr-util

Overview

apr-util is the Apache Portable Runtime utility library. It provides companion functionality for APR itself and is used by software that wants a more portable interface to common platform-specific services. The upstream project describes APR as a set of libraries that present a predictable API across different systems, and apr-util is the utility layer that complements that goal. (apr.apache.org)

In a Linux distribution, this package exists so other packages can build against the APR utility interfaces without bundling their own copies of the code. The exact set of consumers in NiceOS may vary, so maintainers should verify current reverse dependencies before making update decisions.

Purpose and typical use cases

Typical use cases include:

• building software that already depends on APR and needs the APR utility APIs;
• providing shared system libraries for applications that use APR-based helpers instead of private copies;
• packaging a portable runtime dependency used by server-side and infrastructure software.

Typical users are:

• distribution maintainers and RPM packagers;
• developers who build software against APR and apr-util;
• CI/CD maintainers who need reproducible system dependencies;
• administrators maintaining systems that install software linked to APR components.

The upstream documentation shows utility modules for areas such as LDAP, bucket brigades, date routines, DBM routines, crypto routines, URI handling, XML, and related helper APIs. That indicates the library is mainly a support layer for applications rather than an end-user tool by itself. (apr.apache.org)

Upstream project

Upstream project home page: the Apache Portable Runtime project. The project states that its purpose is to provide a predictable and consistent interface to platform-specific implementations, and that apr-util is the companion library to APR. (apr.apache.org)

The upstream versioning document explains that APR projects follow a MAJOR.MINOR.PATCH model with compatibility expectations tied to version level. That document is useful background for maintainers, but package-specific policy still needs to be verified against the branch and the distribution update rules in force at the time of a change. (apr.apache.org)

Dist-git repository contents

This dist-git repository contains the packaging sources for the apr-util RPM:

• SPECS/ — RPM spec files and related packaging logic;
• SOURCES/ — source manifests and integrity metadata used by the build system;
• METADATA/ — repository metadata maintained by the packaging workflow;
• SBOM/ — software bill of materials material, when present for the package.

The large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in the SOURCES manifests and fetches the actual source content through the packaging workflow.

Source storage and integrity policy

For this package, source integrity is tracked through manifest files in SOURCES. Those manifests are the maintainer-facing record of what upstream source material the build is expected to use.

Practical implications for maintainers:

• do not add large upstream archives to the Git tree;
• update the SOURCES manifest data when upstream sources change;
• make sure the spec file and any accompanying packaging metadata still point to the expected upstream inputs;
• verify that the resulting source set matches the intended upstream release or snapshot.

If the packaging workflow regenerates manifest files or auxiliary metadata, review those changes carefully before committing them.

NiceOS maintenance notes

Before updating apr-util, NiceOS maintainers should check:

• whether the upstream change is a routine release update or a more disruptive change;
• whether the spec file needs refreshes in %prep, %build, %install, or subpackage sections;
• whether any packaging patches still apply cleanly or should be dropped;
• whether SOURCES manifests need regeneration because the upstream source set changed;
• whether SBOM/ or other generated metadata should be refreshed if the repository uses it;
• whether the build requires changes to dependency declarations or conditional build flags;
• whether reverse dependencies in NiceOS need rebuilds or compatibility testing.

Risks to consider:

• upstream ABI or API changes that could affect dependent packages;
• build failures caused by newer toolchains, libraries, or stricter compilers;
• accidental drift between the spec file and the source manifest;
• stale packaging patches that are no longer valid or no longer needed.

If any of these points is unclear, NiceOS maintainers should verify it before relying on the update.

Build and verification checklist

For an RPM update or rebuild, maintainers should normally check:

• rpmbuild or the distro build workflow can locate all expected sources from SOURCES;
• the spec file still parses cleanly;
• %prep applies without patch fuzz or rejected hunks;
• the package builds successfully in a clean mock or buildroot environment;
• the resulting RPMs install cleanly and the shared library files land in the expected paths;
• package metadata, subpackages, and file ownership look correct;
• any %check or test suite enabled by the package still passes;
• the update does not introduce unexpected dependency changes;
• dependent packages in the distribution still build or run as expected.

Recommended practical verification steps:

1. Inspect the spec diff before building.
2. Confirm the SOURCES manifest change matches the intended upstream input.
3. Run a clean build in the standard NiceOS RPM environment.
4. Review build logs for new warnings, missing symbols, or test failures.
5. Rebuild or test representative reverse dependencies if the update affects the library interface.

References

• Apache Portable Runtime Project
• APR versioning policy
• APR-util documentation index
• APR utility module index

Russian documentation

See README_RU.md.

Dist-git repository notes

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