LinuxCommandLibrary

createrepo

Create a YUM repository

TLDR

Initialize a basic repository in a directory

$ createrepo [path/to/directory]
copy

Initialize a repository, exclude test RPMs and display verbose logs
$ createrepo [[-v|--verbose]] [[-x|--excludes]] [test_*.rpm] [path/to/directory]
copy

Initialize a repository, using SHA1 as the checksum algorithm, and ignoring symbolic links
$ createrepo [[-S|--skip-symlinks]] [[-s|--checksum]] [sha1] [path/to/directory]
copy

SYNOPSIS

createrepo [options] <directory>

PARAMETERS

--update
    Update an existing repository incrementally, processing only new or changed packages.


--database
    Generate a SQLite database alongside the XML metadata for faster client lookups.


-o <path>, --output <path>
    Specify the output directory for the repository metadata. Defaults to <directory>/repodata/.


-x <glob>, --exclude <glob>
    Exclude packages matching the specified glob pattern from the repository.


--workers <num>
    Set the number of worker processes or threads to use for parallel processing.


--retain-old-md <num>
    Specify how many previous sets of repository metadata to retain. Useful for clients with older metadata caches.


--pretty
    Pretty-print the generated XML metadata files for better human readability.


--c9s
    Generate repository metadata using algorithms specific to CentOS Stream 9, typically for modular content.


DESCRIPTION

createrepo is a utility used to create and update a YUM or DNF repository. It scans a specified directory containing RPM packages and generates the necessary metadata files (XML files, often gzip compressed) that YUM/DNF clients use to locate, verify, and install packages. These metadata files, typically stored in a repodata/ subdirectory, include information about package names, versions, dependencies, file lists, and more. createrepo is essential for setting up local or network-based RPM repositories, enabling efficient package management within an organization or for custom software distribution. It supports incremental updates via the --update option, allowing only new or changed packages to be processed, which significantly saves time and resources for large repositories.

CAVEATS

Creating or updating very large repositories can be resource-intensive (CPU, memory, disk I/O).
The --update option relies on package timestamps and checksums; ensure consistent time synchronization across systems if packages are moved.
Requires write permissions to the target repository directory and its subdirectories.
The original createrepo (Python-based) is often replaced by or acts as a wrapper for createrepo_c (C-based) for performance improvements.

REPOSITORY STRUCTURE

The metadata generated by createrepo is typically placed in a subdirectory named repodata/ within the main repository directory. This directory contains key files such as repomd.xml (the main repository metadata index), primary.xml.gz (containing essential package information), filelists.xml.gz (listing all files within packages), and other.xml.gz (for miscellaneous package data).

INCREMENTAL UPDATES

Using the --update option is crucial for efficiency when maintaining large repositories, as it avoids regenerating all metadata from scratch. Instead, it only processes new or modified RPMs, comparing them against existing metadata and updating only what's necessary. This can drastically reduce the time and computational resources required for repository maintenance.

HISTORY

The createrepo utility emerged with the advent of YUM (Yellowdog Updater, Modified) as the primary package manager for Red Hat-based Linux distributions, succeeding up2date. Initially written in Python, its purpose was to provide the necessary metadata infrastructure for YUM to function effectively by processing RPM packages into a repository structure. Over time, especially with the growth of repository sizes and the demand for improved performance, a C-based implementation, createrepo_c, was developed. This C version is significantly faster and more memory-efficient, often replacing the original Python version or being called by it as a backend. Its development is closely tied to the evolution of YUM and subsequently DNF package managers, remaining a critical component for managing local and remote RPM repositories.

SEE ALSO

yum(8), dnf(8), rpm(8), reposync(1)

Copied to clipboard