NiceOS RPM dist-git source for binaryen
Find a file
NiceOS DistGit Import Bot 44a432e169 Sync binaryen from NiceOS Core snapshot
EVR: 123-1
Lock-SHA256: 9e04967f52f7f76648d2000c77fe47d68ad78e7fe9a8d5c3ab7e2da938ec58b8
Branch: niceos-5.2
2026-05-01 15:43:57 +03:00
METADATA Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
SBOM Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
SOURCES Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
SPECS Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
.gitignore Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
OWNERS Sync binaryen from NiceOS Core snapshot 2026-04-27 21:44:55 +03:00
README.md Sync binaryen from NiceOS Core snapshot 2026-05-01 15:43:57 +03:00
README_RU.md Sync binaryen from NiceOS Core snapshot 2026-05-01 15:43:57 +03:00

binaryen

Overview

Binaryen is the upstream WebAssembly compiler infrastructure and toolchain library used by the binaryen package. Upstream describes it as a C++ library and toolchain for WebAssembly, with utilities for loading, transforming, optimizing, assembling, disassembling, and reducing WebAssembly modules. In a Linux distribution, this package is typically useful as a build-time and development-time tool for WebAssembly workflows, and as a library component for tools that need Binaryen functionality. (github.com)

Purpose and typical use cases

Typical use cases include:

  • optimizing WebAssembly modules during builds;
  • inspecting or transforming .wasm modules in automated pipelines;
  • assembling and disassembling WebAssembly text and binary formats;
  • reducing test cases for debugging WebAssembly-related failures;
  • supporting WebAssembly toolchains and projects that depend on Binaryen functionality. (github.com)

Typical users are:

  • developers working on WebAssembly applications or toolchains;
  • distribution maintainers packaging WebAssembly-related software;
  • CI/CD maintainers running repeatable build and verification steps;
  • release engineers or build engineers who need deterministic module processing;
  • other maintainers who need command-line WebAssembly utilities during troubleshooting.

Upstream project

The upstream project is WebAssembly/binaryen. The upstream repository is the canonical place for project source code, documentation, and official releases. Upstream also publishes release artifacts on GitHub. (github.com)

NiceOS maintainers should verify upstream packaging notes, build requirements, and release behavior against the upstream repository before each update, especially if build tooling or supported build modes change. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

  • SPECS/ — RPM spec files and packaging logic;
  • SOURCES/ — source metadata and manifests used to track imported upstream sources;
  • METADATA/ — package metadata used by the packaging workflow;
  • SBOM/ — software bill of materials data, when present for this package.

The repository is meant to contain packaging metadata, not a full copy of the upstream project tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity metadata in SOURCES/ manifests. This keeps the dist-git history small and makes it easier to review imported sources without committing bulky archives into Git.

When updating the package, maintainers should confirm that the files referenced by SOURCES/ match the intended upstream release or source import, and that any regeneration of manifests or related packaging metadata is done consistently. Do not rely on repository contents alone if a source import step is part of the packaging workflow.

NiceOS maintenance notes

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

  • upstream release notes and build instructions for changes that affect packaging;
  • whether SPECS/ needs changes for new build options, install paths, tests, or bundled assets;
  • whether any files in SOURCES/ need regeneration because the imported source set changed;
  • whether SBOM/ or other metadata needs to be refreshed to match the new source import;
  • whether the update changes build-time dependencies, compiler requirements, or test behavior;
  • whether the update affects reproducibility, generated files, or packaging assumptions used by downstream consumers.

Practical risks to consider:

  • build failures caused by upstream build-system changes;
  • packaging drift if the spec file no longer matches upstream layout;
  • stale manifest data in SOURCES/ after a source refresh;
  • test regressions if the package is used in CI or toolchain workflows;
  • accidental inclusion of unreviewed upstream artifacts.

If any of these points are unclear, NiceOS maintainers should verify them before relying on the update.

Build and verification checklist

Suggested maintainer checklist:

  • confirm the upstream source import is complete and expected;
  • review the spec file for packaging changes;
  • verify that SOURCES/ manifests were refreshed correctly, if applicable;
  • build the RPM in a clean environment;
  • run the package test suite if enabled by the spec;
  • inspect installed files and ownership;
  • check that command-line tools or libraries land in the expected subpackages;
  • verify that the build does not depend on undeclared local state;
  • compare resulting metadata with the intended packaging layout;
  • review any SBOM or generated metadata that should track the import.

References

Russian documentation

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

Dist-git repository notes

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