bzip2

Overview

bzip2 is a data compression utility and libbzip2 is the matching library behind it. Upstream describes it as a program and library for compressing files in the bzip2 format, with command-line tools for compression, decompression, and recovery of damaged archives. In a Linux distribution, this package exists so users and other packages can work with .bz2 data and with software that links against the library. (sourceware.org)

Purpose and typical use cases

Typical uses of this package include:

• compressing files for storage or transfer,
• decompressing .bz2 data produced by other tools or systems,
• embedding libbzip2 in applications that need bzip2-format support,
• recovering data from damaged bzip2 files with bzip2recover when that is appropriate. (sourceware.org)

Typical users include:

• system administrators who need to inspect or handle .bz2 content,
• developers who link against libbzip2,
• CI/CD and release engineers who package or unpack release artifacts,
• security or incident-response engineers who may need to inspect compressed data during investigation.

Upstream project

The upstream project is maintained at Sourceware. The upstream site provides the project home page, documentation, and downloads. The manual documents both the command-line tools and the library interface. NiceOS maintainers should verify upstream packaging notes and release details on the official project pages before making update decisions. (sourceware.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source manifests and other source-control metadata used to describe the imported upstream sources.
• METADATA/ — package metadata used by the dist-git workflow.
• SBOM/ — software bill of materials material, when present in this repository.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps the packaging metadata needed to refer to those sources. This keeps the repository smaller and focuses it on packaging data rather than mirrored upstream payloads.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/. These manifests are the authoritative packaging reference for imported source material in this repository. Do not rely on ad hoc local copies or manually edited source lists when reviewing updates.

Before updating the package, NiceOS maintainers should verify that:

• the upstream release being imported is the intended one,
• the files referenced by the manifests match the upstream release artifacts,
• any packaging metadata that depends on the source layout still matches upstream,
• no source handling rule in the spec file needs to be adjusted because of upstream changes.

NiceOS maintenance notes

Before submitting an update, check the following:

• Review upstream release notes and documentation for any behavior changes that may affect packaging or dependent packages.
• Check whether the spec file needs updates for changed build system behavior, install paths, or test execution.
• Verify whether any files in SPECS/ need regeneration or manual refresh.
• Review SBOM/ content if your packaging workflow expects it to stay aligned with the imported source set.
• Confirm that the SOURCES/ manifests still describe exactly the source material you intend to package.
• Consider downstream compatibility risk for packages that consume bzip2 libraries or command-line behavior.
• If upstream changed documentation structure or release layout, verify that the build and %check logic still behaves as expected.

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

Build and verification checklist

Use the following checklist for RPM maintenance work:

• Inspect the spec file for changed source or patch handling.
• Confirm that the SOURCES/ manifests match the imported upstream material.
• Ensure that the package still builds from the dist-git content without hidden local files.
• Run the package build in a clean environment.
• Run available tests or the package %check phase if the spec enables one.
• Verify that installed files and library metadata match expectations.
• Review generated artifacts for unexpected file additions or removals.
• Check dependent packages if the update can affect ABI, CLI behavior, or documentation paths.
• Validate that any SBOM material remains consistent with the source import.

References

• bzip2 home page
• bzip2 documentation
• bzip2 manual
• bzip2 downloads

Russian documentation

See README_RU.md for the Russian version.

Dist-git repository notes

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