cargo-c

Overview

cargo-c is a Rust tool for building and installing C-compatible libraries from Cargo projects. Upstream describes it as a Cargo applet for C-ABI compatible dynamic and static libraries, with support for generating and installing a pkg-config file and a C header for consumers in C and other FFI-capable languages. (github.com)

In a Linux distribution, this package is useful when upstream Rust software is intended to be consumed through a C ABI rather than only as a Rust crate. NiceOS packages it as a build tool for maintainers and users who need to build or install such projects in a distribution-friendly way. The exact packaging role can vary by project, so maintainers should verify the expected integration before relying on it for a specific crate. (github.com)

Purpose and typical use cases

Typical uses include:

• building a Rust library so it can be installed as a C-compatible shared or static library;
• generating and installing headers and pkg-config metadata for downstream consumers;
• packaging projects that expose an FFI boundary and want distribution builds rather than ad hoc local installs. (github.com)

Typical users include:

• RPM and distribution maintainers;
• developers packaging Rust libraries for C consumers;
• CI/CD maintainers validating build and install steps;
• engineers working on cross-language integration through a stable C ABI. (github.com)

Upstream project

Upstream project: lu-zero/cargo-c. The upstream README explains the tool’s main workflow, shows example cargo cbuild, cargo ctest, and cargo cinstall commands, and documents metadata under package.metadata.capi for controlling header and library generation. (github.com)

If you need a deeper reference for the crate itself, Docs.rs also publishes crate documentation for cargo-c. (docs.rs)

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 by the packaging workflow;
• METADATA/ — repository metadata used by the dist-git tooling;
• SBOM/ — software bill of materials data, when present. (github.com)

The Git repository is intentionally not a mirror of all upstream source material. Large upstream source archives are kept out of Git, and source integrity is tracked through manifest files under SOURCES/. Maintainers should treat the manifest as the packaging record and not as a replacement for the upstream release archive. (github.com)

Source storage and integrity policy

NiceOS keeps large upstream source archives outside this Git repository on purpose. The repository records the expected source set through manifest files in SOURCES/, which makes the package easier to review and update without storing bulky release artifacts in Git. (github.com)

For maintainers, this means:

• verify that the manifest entries still match the intended upstream source set;
• update or regenerate source metadata if the upstream packaging layout changes;
• do not rely on Git history alone as evidence of source integrity. (github.com)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream changed the build or install workflow described in its documentation;
• whether package.metadata.capi settings, header generation, or library naming need review;
• whether any generated packaging metadata must be refreshed;
• whether the update changes the way downstream crates or C consumers are expected to build against the produced artifacts. If any of these points are unclear, maintainers should verify them against upstream before relying on them. (github.com)

Practical update tasks often include:

• refreshing the spec file if build flags or cargo subcommands change;
• checking whether source manifests in SOURCES/ need regeneration;
• reviewing SBOM/ data if NiceOS keeps it in sync for this package;
• confirming that the repo metadata still describes the current packaging layout. (github.com)

Risks to consider during an update:

• changes in upstream Cargo metadata can affect header or library generation;
• changes in the upstream build toolchain requirements can break distro builds;
• FFI-facing packages can require downstream rebuilds when their ABI-relevant interface changes. The exact impact should be verified from upstream release notes or build documentation. (github.com)

Build and verification checklist

For RPM maintenance, a reasonable checklist is:

• confirm the upstream source reference and manifest entries are correct;
• review the spec for changes in build arguments, install paths, or cargo subcommands;
• run a clean build in the target NiceOS environment;
• verify the package installs the expected binaries, headers, and metadata files;
• if the package produces FFI artifacts, check that the generated header and pkg-config data are present and consistent;
• run any available test or smoke-test step from the upstream workflow;
• inspect the resulting RPM contents and file ownership for packaging regressions. (github.com)

If the package is used by downstream C or mixed-language projects, also verify that those consumers still build against the updated artifacts. That compatibility check is a maintainer responsibility and should not be assumed from the package alone. (github.com)

References

• Upstream project: lu-zero/cargo-c
• Docs.rs crate documentation for cargo-c
• Docs.rs package page for cargo_c

Russian documentation

See README_RU.md for the Russian documentation.

Dist-git repository notes

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