createrepo_c

Overview

createrepo_c is the upstream project behind the createrepo family of tools, implemented in C. It is used to create and update RPM repository metadata so that package managers can work with a repository of RPM packages. The project also provides related repository-management tools, and its Python bindings and documentation are published by the upstream project. (github.com)

In a Linux distribution, this package is typically useful for building and maintaining package repositories rather than for end-user desktop use. NiceOS packages it so maintainers, release engineers, CI/CD pipelines, and repository administrators can generate repository metadata in a reproducible way. That role should be verified against the distro’s packaging policy if a local repository layout uses nonstandard workflows. (github.com)

Purpose and typical use cases

Typical use cases include:

• generating repository metadata for a directory of RPM packages;
• refreshing metadata after packages are added, removed, or replaced;
• maintaining local mirrors, internal package repositories, and build artifacts;
• using repository-generation steps in CI/CD jobs or release automation;
• handling repository metadata as part of distribution or staging workflows.

Typical users include:

• repository and mirror administrators;
• RPM packagers and release engineers;
• CI/CD maintainers who publish repository contents;
• developers who test package installation from a local repository;
• security or compliance teams that need repeatable repository metadata generation.

Upstream project

Upstream project home: createrepo_c.

The upstream project provides build and test guidance, Python documentation, and notes about the differences between createrepo_c and the older createrepo behavior. NiceOS maintainers should check upstream documentation when changing build options, packaging flags, or repository-generation behavior. (github.com)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source-manifest metadata used to describe upstream inputs;
• METADATA/ — repository metadata used by the dist-git workflow;
• SBOM/ — software bill of materials data, when maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. Maintainers should use those manifests to confirm that the expected upstream inputs are present and unchanged before rebuilding or updating the package.

Source storage and integrity policy

NiceOS follows a split-storage model for package sources:

• Git stores the spec, manifest metadata, and related packaging files;
• large upstream archives stay out of the repository;
• integrity information is recorded in SOURCES/ manifests rather than embedded as ad hoc notes.

Before any update, maintainers should verify that the source manifest still matches the intended upstream source set and that no unexpected files were added or removed. If the package uses generated files, those files should be regenerated from the verified source set rather than edited manually.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes and build instructions for changes in build tooling or behavior;
• whether the spec file needs refreshes for patches, macros, or build options;
• whether any generated packaging files need regeneration, including source manifests or SBOM data if your workflow uses them;
• whether upstream changed repository-metadata behavior in a way that could affect compatibility with existing NiceOS workflows;
• whether the update changes file layout, optional features, or test expectations in a way that should be reflected in packaging.

Risk areas to consider:

• metadata generation changes that alter repository output;
• build option changes that affect the produced binaries or Python bindings;
• test or documentation regeneration requirements;
• downstream scripts that may assume older command-line behavior.

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

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Review upstream changes and packaging diffs.
2. Confirm that SOURCES/ still reflects the intended upstream input set.
3. Check whether the spec file needs patch refreshes or macro adjustments.
4. Rebuild the package in the target branch environment.
5. Run package tests if they are enabled in the spec or build workflow.
6. Validate that installed files, subpackages, and generated metadata match expectations.
7. Inspect build logs for warnings about missing optional features, documentation, or tests.
8. Confirm that any regenerated metadata files are committed when required by the packaging workflow.
9. Verify that the resulting package still behaves correctly for repository generation in a clean test repository.

References

• Upstream project repository
• Upstream Python documentation
• Upstream Python API reference

Russian documentation

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

Dist-git repository notes

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