brotli

Overview

Brotli is a general-purpose lossless compression format and implementation used to compress and decompress data. Upstream describes it as a compression algorithm and format defined by the Brotli specification in RFC 7932. In a Linux distribution, this package is typically included so software and users can work with Brotli-compressed data in a standard, packaged form. (github.com)

Purpose and typical use cases

Typical use cases include:

• compressing files or data streams for storage or transport;
• decompressing Brotli data created by other tools or services;
• supporting software that expects the Brotli format during builds, packaging, or runtime processing;
• providing a packaged implementation that can be reused by distribution tooling and other packages.

Typical users include:

• distribution maintainers who package or rebuild software that depends on Brotli;
• developers who need Brotli compression or decompression in their applications;
• CI/CD maintainers who validate builds that use Brotli data;
• administrators and users who need a command-line or library package for handling Brotli-compressed content.

Upstream project

The upstream project is the Google-maintained Brotli repository. Its README identifies the project as the Brotli compression format and states that it is released under the MIT License. The authoritative format specification is RFC 7932. (github.com)

Dist-git repository contents

This dist-git repository is structured as follows:

• SPECS/ — RPM spec file(s) and packaging logic;
• SOURCES/ — source integrity metadata and manifest files used by the packaging workflow;
• METADATA/ — package metadata used by the dist-git tooling;
• SBOM/ — software bill of materials material, if maintained for this package.

Large upstream source archives are intentionally not stored in this Git repository. Only the packaging metadata and integrity manifests are kept here.

Source storage and integrity policy

Source files are managed through manifest files under SOURCES/. These manifests record which upstream sources are expected by the package build and allow maintainers to verify that the imported sources match what the repository expects, without keeping large archives in Git.

When updating the package, NiceOS maintainers should verify that:

• the upstream source still matches the expected manifest entries;
• any changed source layout is reflected in the spec or auxiliary packaging files;
• the source import process has not introduced unexpected files;
• no local packaging patches are now obsolete or need adjustment.

NiceOS maintenance notes

Before updating this package, check the following:

• confirm that the upstream project and release you are importing are the intended ones;
• verify whether the spec file needs a new source manifest entry or a refreshed packaging note;
• review any patches carried by NiceOS for applicability against the new upstream tree;
• check whether any generated packaging files need regeneration, including metadata maintained alongside the spec;
• review the SBOM material, if present, for consistency with the imported sources;
• confirm that the license information still matches the upstream project and packaged files;
• evaluate whether the update changes build flags, build system behavior, or installed artifacts in a way that affects dependent packages.

Risks to consider:

• upstream build or test changes may require spec adjustments;
• source layout changes may break patch application or file installation paths;
• regenerated metadata may differ from what is currently tracked in dist-git;
• dependent packages may expect a specific library or command-line behavior, so rebuilds should be checked carefully.

Build and verification checklist

For RPM maintenance work, a practical checklist is:

1. Review the spec file for source, patch, and subpackage changes.
2. Verify that SOURCES/ manifests still correspond to the imported upstream content.
3. Check whether METADATA/ or SBOM/ needs regeneration after the update.
4. Run the package build in a clean environment.
5. Inspect build logs for missing files, patch failures, or unexpected warnings.
6. Run the package test suite if the spec enables tests and if they are reliable in the build environment.
7. Verify the installed payload and file list against expectations.
8. Check reverse dependencies or dependent packages if the update may affect ABI, CLI behavior, or packaging paths.
9. Review license files and copyright metadata after the import.

References

• Upstream project repository
• Brotli Compressed Data Format, RFC 7932

Russian documentation

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

Dist-git repository notes

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