corosync

Overview

Corosync is the Corosync Cluster Engine. Upstream describes it as a group communication system with features used to build high-availability behavior in applications. In practice, it is part of the infrastructure that helps clustered software exchange messages, track quorum, and coordinate state across nodes. (corosync.github.io)

For NiceOS, this package exists so that clustered services can rely on the distribution’s packaged Corosync components rather than building and tracking upstream sources manually. That makes the software easier to ship, update, and verify in a distribution workflow.

Purpose and typical use cases

Typical uses include:

• cluster membership and group communication,
• quorum notification for clustered applications,
• coordination of high-availability stacks,
• integrations with software that expects Corosync as its messaging and quorum layer. (corosync.github.io)

Typical users include:

• cluster administrators,
• platform and infrastructure engineers,
• developers working on high-availability applications,
• release and CI/CD maintainers packaging cluster software,
• security engineers reviewing build inputs and repository integrity.

Upstream project

The upstream project is maintained in the corosync/corosync GitHub repository and documented on the project website. The official site states that Corosync is used as a high-availability framework by projects such as Pacemaker and Asterisk. (github.com)

Upstream references:

• project website,
• GitHub source repository,
• GitHub releases page for upstream release artifacts. (corosync.github.io)

Dist-git repository contents

This dist-git repository is organized as follows:

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

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in SOURCES/ manifests so maintainers can verify what should be fetched and built without committing bulky upstream archives into Git.

Source storage and integrity policy

The packaging model for this repository is based on tracked source manifests rather than storing full upstream archives in Git. When updating the package, maintainers should confirm that:

• the manifest in SOURCES/ matches the intended upstream source set,
• the imported source content corresponds to the expected upstream release or commit,
• any generated metadata remains consistent with the spec and repository layout,
• no unintended files were added or removed during source import.

Do not rely on unreviewed source changes. If the source layout or upstream release process changes, NiceOS maintainers should verify the import procedure before depending on it.

NiceOS maintenance notes

Before updating this package, check the following:

• review upstream release notes and changelog for packaging-impacting changes,
• confirm whether the spec file needs adjustments for build flags, install paths, service units, or subpackages,
• check whether any files under SOURCES/ need regeneration,
• confirm that SBOM/ content still matches the packaged source set if the repository uses it,
• verify that repository metadata under METADATA/ still reflects the current package structure,
• review downstream patches for applicability and potential rebasing,
• assess whether the update changes runtime behavior, configuration syntax, or compatibility expectations for clustered deployments,
• check whether maintainer documentation or examples mention paths or options that changed upstream.

Main risks to consider:

• cluster software is sensitive to configuration mismatches,
• changes in defaults may alter quorum or membership behavior,
• build-time dependency changes may affect package composition,
• upstream source layout changes may require refreshes in the spec or source manifests.

If any of these points are unclear, NiceOS maintainers should verify them before publishing an update.

Build and verification checklist

Use this checklist when preparing an RPM update:

• verify that the spec file still parses cleanly,
• confirm that the source manifests in SOURCES/ match the imported upstream material,
• rebuild the SRPM and RPMs in a clean environment,
• review build logs for warnings or failed feature detection,
• run any available package or upstream test suite that is practical in the build environment,
• check installed file lists, permissions, and ownership expectations,
• verify that service-related packaging changes do not break enablement or startup paths,
• inspect generated debug, devel, and documentation subpackages if applicable,
• compare installed paths and provided library or binary names against the previous package,
• test basic runtime startup in a controlled cluster-like environment when feasible.

References

• Corosync project website
• Corosync source repository
• Corosync releases

Russian documentation

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

Dist-git repository notes

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