apr

Overview

APR, the Apache Portable Runtime, provides a portability-focused runtime library with a consistent API over platform-specific system interfaces. The upstream project describes it as a way for software developers to target a predictable interface instead of handling many operating-system differences directly. (apr.apache.org)

In NiceOS, this package exists as a distribution build of that library so other software can link against a maintained system copy instead of bundling its own. That role is a general packaging inference rather than a claim about any single consumer package, so NiceOS maintainers should verify actual reverse dependencies when planning updates. (apr.apache.org)

Purpose and typical use cases

Typical uses of APR include:

• providing a portable C runtime layer for software that needs filesystem, process, threading, socket, memory pool, and related system abstractions;
• supporting applications that are designed to run across multiple Unix-like platforms with fewer platform-specific code paths;
• serving as a shared system library for projects that depend on APR instead of copying portability code into each project. (apr.apache.org)

Typical users include:

• package maintainers who need a shared system library for dependent RPMs;
• developers working on software that uses APR APIs directly;
• build and CI/CD maintainers who need reproducible dependency builds;
• administrators who install or update system packages and want a maintained runtime library from the distribution. This last point is a practical packaging use case, not a promise about any particular deployment pattern. (apr.apache.org)

Upstream project

Upstream is the Apache Portable Runtime project. Its homepage and documentation cover the project mission, API documentation, and related APR subprojects. The APR documentation site is a useful reference when checking whether a packaging update aligns with upstream interfaces and documentation. (apr.apache.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — metadata and manifest files used to track source inputs.
• METADATA/ — repository metadata used by the packaging workflow.
• SBOM/ — software bill of materials material, when present in the packaging workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, which record what should be fetched for the build. The exact manifest format may vary by package or tooling, so NiceOS maintainers should inspect the repository contents before relying on automation. (apr.apache.org)

Source storage and integrity policy

The repository policy for this package is to keep source archives out of Git and rely on SOURCES/ manifests for integrity tracking. That keeps the Git history smaller and avoids storing large upstream tarballs in the dist-git tree. The manifests are the place to verify that the expected upstream input matches what the package build uses. (apr.apache.org)

For updates, maintainers should confirm that:

• the manifest still points to the intended upstream source;
• any additional patch files remain applicable to the new upstream tree;
• the spec file still builds against the expected headers and libraries;
• repository metadata and SBOM material remain consistent if the package workflow regenerates them. This is a maintainer check, not a claim that these files always need changes. (apr.apache.org)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should verify:

• whether upstream changed any public APIs or documented behavior that could affect dependent packages;
• whether distro patches still apply cleanly and are still needed;
• whether any generated packaging files need regeneration, including source manifests or SBOM material if the local workflow uses them;
• whether the update affects dependent builds in the repository, especially packages that link to APR or use its headers;
• whether the spec file needs refreshes in build requirements, file lists, or compatibility handling. If any of these points are unclear, maintainers should verify them against the local packaging rules and the upstream release documentation before merging. (apr.apache.org)

Practical risks to consider:

• build failures caused by changed upstream headers or compile-time checks;
• downstream ABI or API expectations in packages that consume APR;
• stale patches that no longer apply cleanly;
• packaging drift between spec, manifests, and repository metadata. These are normal maintenance risks, not claims about a specific defect in the package. (apr.apache.org)

Build and verification checklist

A typical RPM maintainer checklist for this repository:

1. Review upstream release notes and documentation for interface or build changes.
2. Confirm the SOURCES/ manifest matches the intended upstream input.
3. Check whether any local patches still apply and are still justified.
4. Verify the spec file build requirements, configure options, and file lists.
5. Build in the target NiceOS branch environment.
6. Run package tests, if available in the SRPM or local workflow.
7. Inspect installed files, shared library metadata, and dependency output.
8. Check that dependent packages in the distribution still build or at least still resolve correctly.
9. Regenerate repository metadata or SBOM material only if the packaging workflow expects it.
10. Review the final diff for unintended packaging changes. (apr.apache.org)

References

• Apache Portable Runtime project home
• APR documentation main page
• APR documentation topic index

Russian documentation

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

Dist-git repository notes

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