Koji provides some limited features for exporting repositories of RPMs. Please note that Koji is a build system, not a repository manager, and these features are secondary. If you need more robust repository generation than Koji provides, then you may want to look into using pungi.
Koji’s internal repositories¶
Koji uses yum repositories as part of its build process for RPMs. These repositories are used by the builders to generate buildroots. Their generation is focused on that purpose, and they are not really suitable for export. However, they can be useful for simple cases.
Koji’s internal repositories can be accessed at
For a given tag name, there will be multiple repo ids over time as tag content
The current repo for a given tag can be determined with a call to
For convenience, Koji also maintains a “latest” symlink for each tag:
Please note that this symlink changes over time, which could break a yum transaction.
The simplest way to create a distribution-ready repo is to use the
It allows users with access to generate a more robust yum repository from the
contents of a given tag.
These repos differ from the internal ones in several key ways:
generation is user-controlled via the
supports using signed rpms
allows for more customized comps data
supports deltarpm generation
can split debuginfo into separate repos
can generate zchunk files
In order to use the
dist-repo command, a user must satisfy one of the
satisfy the requirements of the
For more information about hub policies, see Defining Hub Policies.
dist-repo command takes a tag name and one or more key ids for signing keys.
koji dist-repo [options] <tag> <key_id> [<key_id> …]
tag argument must be a valid tag name.
The resulting repository will be based on the contents of that tag.
Any valid tag will work, whether or not it has an associated target.
Koji will attempt to find a signed copy for each rpm matching one
of the given
key_id arguments (searching in the order given).
Normally, Koji will error if there is no matching signed copy for any of the
This behavior can be modified with the
key_id argument may be omitted entirely if the
--allow-missing-signatures option is specified.
Koji will export the repository to
The current dist repo for a given tag can be determined with a call to
getRepo(dist=True). Similar to internal build repos, Koji also maintains a
“latest” symlink for each tag:
Various features of repo generation (e.g. multilib support, delta rpms, or
zchunk files) are controlled via command options.
For a full list of options, see
koji dist-repo --help.
Koji Hub plugin
Fedora release engineering uses a hub plugin tag2distrepo to automatically export dist-repos for certain tags.
If you’re aiming to have more control about repositories, varieties of distribution flavours, etc. use pungi which can create whole composes and which uses Koji for some of the subtasks. Pungi + koji is what Fedora currently uses for composes.