zchunk

English

Overview

zchunk is a file format and associated tools for producing compressed files that are split into independent chunks. The format is designed so that clients can retrieve only the chunks that changed between revisions instead of downloading the entire file again. Upstream also documents utilities for creating, reading, compressing, decompressing, and downloading zchunk files. (github.com)

In a Linux distribution, this package is typically used as a library and tool set for software that needs chunked, delta-friendly compressed artifacts. The exact set of reverse dependencies and distribution roles should be verified by NiceOS maintainers from the repository metadata and build results.

Purpose and typical use cases

Typical use cases include:

• publishing files that change incrementally and are fetched over HTTP ranged requests;
• reducing transfer size for updated metadata or content that is redistributed in revisions;
• reading or decompressing zchunk files in build, mirror, or packaging workflows;
• generating or using zchunk dictionaries when an upstream workflow requires them. (github.com)

Typical users include:

• distribution maintainers who package or publish chunked update payloads;
• build and CI/CD maintainers who validate compressed artifacts in pipelines;
• developers integrating zchunk-aware tooling into applications or packaging workflows;
• security or release engineers who need reproducible source handling and file integrity checks in the packaging process.

Upstream project

The upstream project is zchunk/zchunk. Upstream describes zchunk as a file format designed for highly efficient deltas while maintaining compression, and it documents the format in the repository’s zchunk_format.txt. (github.com)

NiceOS maintainers should verify the upstream repository layout and packaging assumptions before each update, especially if upstream changes its build system, test layout, or format documentation.

Dist-git repository contents

This dist-git repository is expected to contain the following tracked areas:

• SPECS/ — RPM spec files and package policy adjustments;
• SOURCES/ — source manifests and related metadata used to track imported upstream sources;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, if maintained for this package.

The Git repository does not store large upstream source archives directly. Those archives are intentionally kept out of dist-git, while source integrity is tracked through manifest files in SOURCES/.

Source storage and integrity policy

NiceOS dist-git keeps large upstream source archives outside this Git repository. Instead, the repository tracks source provenance and integrity through manifest files in SOURCES/.

Maintainers should treat the manifest as the source-control record for imported upstream payloads. Before updating the package, verify that the manifest and any accompanying metadata still match the intended upstream release artifacts. Do not rely on mutable local files, ad hoc downloads, or manual edits outside the repository workflow.

This README intentionally does not include concrete archive hashes or checksum values. Those values are expected to be maintained in the repository metadata and regenerated only when the imported source set changes.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check the following:

• confirm the upstream repository and the intended source revision;
• review upstream release notes, format changes, and build-system changes;
• verify whether any files in SPECS/, SOURCES/, METADATA/, or SBOM/ need regeneration;
• confirm that source manifests in SOURCES/ still match the imported upstream payload;
• review whether tests, examples, or documentation changes affect the packaging policy;
• consider whether ABI, API, or on-disk format changes require downstream coordination.

Potential risks to consider include:

• upstream build or test changes that alter the package build outcome;
• format changes that affect compatibility with existing consumers;
• manifest drift caused by incomplete source refreshes;
• packaging changes that require spec maintenance beyond a simple version bump.

If any of these points are unclear, NiceOS maintainers should verify them against upstream documentation and the build logs for the target branch.

Build and verification checklist

For RPM maintenance, use a checklist similar to the following:

1. Confirm the upstream source revision and expected build inputs.
2. Refresh SOURCES/ manifests if the imported source set changed.
3. Review the spec file for build-system changes, dependency adjustments, or test toggles.
4. Build the package in a clean environment.
5. Run the package test suite when available and record failures.
6. Inspect the build logs for file installation paths, missing resources, and unexpected generated artifacts.
7. Verify that installed files match the intended package split.
8. Check that no large upstream archives were committed to Git.
9. Confirm that SBOM/ and METADATA/ are still consistent with the package update policy.
10. Review the final binary package for ownership, permissions, and payload completeness.

References

• Upstream repository
• Upstream README
• Format documentation
• Upstream introduction
• Upstream overview

Русский

Обзор

zchunk — это формат файлов и набор утилит для создания сжатых файлов, разделённых на независимые блоки. Формат предназначен для сценариев, где клиент может получать только изменившиеся блоки между версиями вместо повторной загрузки всего файла. В upstream также описаны утилиты для создания, чтения, сжатия, распаковки и загрузки zchunk-файлов. (github.com)

В Linux-дистрибутиве этот пакет обычно используется как библиотека и набор инструментов для программ, которым нужны chunked- или delta-oriented compressed artifacts. Точный набор обратных зависимостей и роль пакета в дистрибутиве следует проверять по метаданным репозитория и результатам сборки NiceOS.

Назначение и типовые сценарии использования

Типовые сценарии использования:

• публикация файлов, которые изменяются по частям и загружаются через HTTP ranged requests;
• уменьшение объёма передачи при обновлении метаданных или контента, распространяемого по версиям;
• чтение и распаковка zchunk-файлов в сборочных, зеркальных или упаковочных процессах;
• создание или использование zchunk dictionaries, если это требуется upstream-процессом. (github.com)

Типовые пользователи:

• сопровождающие дистрибутива, которые упаковывают или публикуют данные с инкрементальными обновлениями;
• инженеры CI/CD и сборочных систем, которые проверяют сжатые артефакты в пайплайнах;
• разработчики, интегрирующие zchunk-aware инструменты в приложения или процессы упаковки;
• инженеры по безопасности и релизу, которым нужен воспроизводимый контроль исходных файлов и проверка целостности в упаковочном процессе.

Upstream-проект

Upstream-проект — zchunk/zchunk. В upstream zchunk описан как формат файлов, рассчитанный на эффективные delta-обновления при сохранении сжатия; документация формата находится в файле zchunk_format.txt в репозитории. (github.com)

Сопровождающим NiceOS следует перед каждой обновляющей поставкой проверить upstream-репозиторий и допущения упаковки, особенно если upstream изменил систему сборки, структуру тестов или документацию формата.

Содержимое dist-git репозитория

Ожидается, что этот dist-git репозиторий содержит следующие области:

• SPECS/ — RPM spec-файлы и настройки политики пакета;
• SOURCES/ — манифесты исходных файлов и связанные метаданные для отслеживания импортированного upstream-кода;
• METADATA/ — метаданные репозитория для упаковочного процесса;
• SBOM/ — материалы software bill of materials, если они ведутся для этого пакета.

Git-репозиторий не хранит большие upstream-архивы исходников напрямую. Такие архивы намеренно не помещаются в dist-git; вместо этого целостность исходных файлов отслеживается через файлы-манифесты в SOURCES/.

Политика хранения исходных файлов и контроля целостности

В dist-git NiceOS большие upstream-архивы исходников не хранятся внутри этого Git-репозитория. Вместо этого происхождение и целостность исходников фиксируются через файлы-манифесты в SOURCES/.

Сопровождающим следует рассматривать манифест как запись в системе контроля версий для импортированного upstream-пакета. Перед обновлением пакета нужно убедиться, что манифест и связанные метаданные соответствуют нужным upstream-артефактам. Не следует опираться на изменяемые локальные файлы, разовые загрузки или ручные правки вне стандартного процесса репозитория.

Этот README намеренно не содержит конкретных хэшей архивов или значений checksum. Такие значения должны поддерживаться в метаданных репозитория и пересоздаваться только при изменении набора импортируемых исходников.

Замечания по сопровождению в НАЙС.ОС

Перед обновлением пакета сопровождающим NiceOS следует проверить следующее:

• подтвердить upstream-репозиторий и требуемую ревизию исходников;
• изучить заметки о выпуске upstream, изменения формата и изменения системы сборки;
• проверить, требуется ли регенерация файлов в SPECS/, SOURCES/, METADATA/ или SBOM/;
• убедиться, что манифесты исходников в SOURCES/ по-прежнему соответствуют импортируемому upstream-пакету;
• проверить, влияют ли изменения в тестах, примерах или документации на политику упаковки;
• оценить, требуют ли изменения ABI, API или формата данных координации с потребителями в дистрибутиве.

Возможные риски:

• изменения upstream-сборки или тестов, влияющие на результат сборки пакета;
• изменения формата, которые могут повлиять на совместимость с существующими потребителями;
• расхождение манифестов из-за неполного обновления исходников;
• изменения упаковки, требующие доработки spec-файла, а не только обновления версии.

Если какой-либо из пунктов неясен, сопровождающим NiceOS следует проверить его по документации upstream и журналам сборки для целевой ветки.

Контрольный список сборки и проверки

Для сопровождения RPM используйте следующий контрольный список:

1. Подтвердить upstream-ревизию и ожидаемые входные данные сборки.
2. Обновить манифесты SOURCES/, если набор импортируемых исходников изменился.
3. Проверить spec-файл на изменения системы сборки, зависимостей или запусков тестов.
4. Собрать пакет в чистой среде.
5. Запустить тесты пакета, если они доступны, и зафиксировать ошибки.
6. Проверить журналы сборки на пути установки файлов, отсутствующие ресурсы и неожиданные сгенерированные артефакты.
7. Убедиться, что установленные файлы соответствуют ожидаемому разбиению пакета.
8. Проверить, что большие upstream-архивы не были добавлены в Git.
9. Убедиться, что SBOM/ и METADATA/ остаются согласованными с политикой обновления пакета.
10. Проверить итоговый бинарный пакет на принадлежность файлов, права доступа и полноту payload.

Ссылки

• Upstream-репозиторий
• Upstream README
• Документация формата
• Введение в upstream
• Обзор upstream

Dist-git repository notes

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