boost

Overview

Boost is a collection of portable C++ source libraries. It is used as a shared upstream code base for many reusable components that complement the C++ standard library and are commonly needed in application and systems development. The upstream project describes Boost as a set of free, peer-reviewed, portable C++ source libraries. (boost.org)

In a Linux distribution, the package exists so these libraries can be built, updated, and maintained in a controlled way with RPM packaging, rather than requiring each consumer to vendor its own copy. That makes the package useful to developers, build engineers, and distribution maintainers who need a consistent packaged source of Boost components.

Purpose and typical use cases

Typical uses of Boost in a distribution environment include:

• building C++ software that depends on Boost headers and libraries;
• providing a packaged dependency for other RPMs that expect Boost to be available from the distribution;
• letting maintainers keep upstream sources, patches, and packaging metadata in one place;
• supporting CI/CD and rebuild workflows that need reproducible packaging inputs.

Typical users include:

• application developers working on C++ software;
• distribution and package maintainers;
• CI/CD maintainers who build dependent packages;
• build and release engineers;
• occasionally security or compliance reviewers who need to inspect source provenance and packaging metadata.

Upstream project

The upstream Boost project is available from the main Boost web site and documentation portal. The project positions Boost as portable C++ source libraries that are broadly useful and intended to work well with the C++ standard library. (boost.org)

Stable upstream references:

• project home page: http://www.boost.org
• documentation portal: https://www.boost.org/doc/

If you need to verify a package change against upstream behavior, check the matching upstream release notes, documentation for the affected library, and any project guidance for build or test changes.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and any packaging logic.
• SOURCES/ — source integrity metadata and manifest files used by the packaging workflow.
• METADATA/ — repository metadata used by the package maintenance process.
• SBOM/ — software bill of materials artifacts, when present.

The repository does not store large upstream source archives directly in Git. Instead, the source payload is handled outside the Git tree, and the SOURCES manifests record the expected source inputs and integrity metadata needed by the packaging process.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository.

For this package, source integrity is tracked through manifest files in SOURCES/. Those manifests are the maintainer-visible record of which upstream sources are expected for the package build. The exact checksum values are intentionally not repeated here.

When updating the package, verify that:

• the manifest entries still match the intended upstream source set;
• any referenced source files are the correct upstream release artifacts;
• no packaging patch accidentally targets the wrong upstream layout;
• the source policy used by NiceOS is still being followed.

If the upstream source layout changes, NiceOS maintainers should verify whether the manifests or packaging rules need to be updated together.

NiceOS maintenance notes

Before updating this package, check the following:

• whether the upstream release changes build behavior, library layout, or documented requirements;
• whether any downstream patches still apply cleanly;
• whether SPECS/ needs adjustments for build flags, subpackages, file lists, or automated tests;
• whether SOURCES/ manifests must be regenerated or refreshed;
• whether SBOM/ content, if used, needs regeneration;
• whether the update changes dependency edges for packages that consume Boost.

Risks to consider:

• Boost is a large upstream project, so even small version changes may affect dependent builds;
• template-heavy C++ code can expose compiler or toolchain differences during rebuilds;
• upstream documentation or test coverage may change in ways that matter to packaging, even when the library API appears stable.

If any detail is uncertain, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

A practical RPM-maintainer checklist for this repository:

• review the upstream release notes and documentation for the affected components;
• confirm that the new upstream sources are the intended ones for the packaging update;
• confirm that SOURCES/ manifests were updated correctly;
• inspect spec changes for removed or added patches;
• rebuild the package in a clean environment;
• run the package test suite or the relevant subset of tests, if enabled;
• verify that installed files and subpackages still match expectations;
• check for unexpected dependency changes in the resulting RPMs;
• review build logs for new warnings or failures;
• if SBOM artifacts are maintained, confirm that they are regenerated consistently.

If the repository is used for dependent package builds, verify at least one representative reverse dependency after the update.

References

• Boost project home
• Boost documentation portal
• Boost C++ Libraries documentation

Russian documentation

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

Dist-git repository notes

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