capnproto

Overview

Cap'n Proto is a data interchange format and capability-based RPC system. In practical terms, it is used to define schemas for structured data and to generate code that can read, write, and exchange that data efficiently across processes or machines. It is commonly packaged in Linux distributions because many projects use it as a runtime library and code generator rather than vendor their own copy.

For NiceOS, this package provides the upstream Cap'n Proto implementation in a form that can be built, updated, and tracked with normal RPM packaging workflows. If your distribution uses this package in a broader stack, NiceOS maintainers should verify the exact dependency chain before assuming a particular role for it.

Purpose and typical use cases

Typical use cases include:

• defining binary schemas for application data exchange
• generating language bindings or schema-related code from .capnp files
• implementing RPC between components in the same system or across the network
• building software that needs structured messages without hand-writing every serializer

Typical users include:

• developers who compile or consume Cap'n Proto schemas
• distribution and package maintainers who need a packaged runtime and tools
• CI/CD maintainers who build projects that depend on Cap'n Proto during the build
• system administrators who deploy software with Cap'n Proto-based components
• security engineers who review how capability-based interfaces are used in an application stack

Upstream project

The upstream project is maintained at the Cap'n Proto site and source repository. The official documentation describes Cap'n Proto as a schema-based data format and RPC system, with documentation for the schema language, FAQ, and RPC protocol available from the project site. (capnproto.org)

Useful upstream references:

• Project home: capnproto.org
• Source repository: GitHub - capnproto/capnproto
• RPC documentation: RPC Protocol
• Schema language documentation: Schema Language
• FAQ: Cap'n Proto FAQ

Dist-git repository contents

This dist-git repository normally contains the packaging metadata needed to build the RPM in NiceOS:

• SPECS/ — RPM spec files and related packaging logic
• SOURCES/ — source manifests and other source-control metadata used by the packaging workflow
• METADATA/ — repository metadata used by the dist-git tooling and package management process
• SBOM/ — software bill of materials artifacts, when maintained for this package

The repository is intended to track packaging inputs and policy, not to mirror the full upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, the packaging workflow keeps source-integrity metadata in the SOURCES manifests. This lets maintainers track which upstream source material belongs to the package without committing bulky upstream archives into dist-git.

When updating the package, maintainers should verify that the SOURCES manifest entries still match the intended upstream source set and that the packaging metadata points to the correct upstream material. The exact checksum values are intentionally not repeated here.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release notes or changelog mention build-system, API, or schema changes that affect the packaged RPM
• whether any patched files in SPECS/ need to be refreshed, dropped, or reordered
• whether source-manifest entries in SOURCES/ need to be regenerated to reflect new upstream inputs
• whether SBOM/ artifacts need to be updated if NiceOS tracks them for this package
• whether the package still builds cleanly with the distribution toolchain and macros used in NiceOS
• whether any downstream consumers expect generated files, installed paths, or helper tools to remain stable

Risks to consider:

• schema or API changes may break dependent packages at build time or runtime
• packaging changes may affect generated code, installed binaries, or helper scripts
• changes in the upstream build system may require spec-file adjustments
• source-manifest mistakes can point the build to the wrong upstream content

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Review the upstream release notes and compare them with the current packaging rules.
2. Verify that the source manifests in SOURCES/ describe the intended upstream content.
3. Check whether any patches in SPECS/ still apply cleanly and remain justified.
4. Build the SRPM and RPMs in a clean mock or equivalent build environment.
5. Run the package test suite or upstream self-tests if they are available and practical in the build environment.
6. Confirm that installed files, library paths, and generated tools match what downstream consumers expect.
7. Inspect the resulting RPM metadata and, if used, the SBOM artifacts.
8. Review the final build logs for warnings, missing dependencies, or disabled features that matter to NiceOS.

References

• capnproto.org
• GitHub - capnproto/capnproto
• RPC Protocol
• Schema Language
• Cap'n Proto FAQ

Russian documentation

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

Dist-git repository notes

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