koji-untag-build
Remove Koji build from tag
TLDR
Remove a tag from one or more builds
Untag all versions of the package in this tag
Untag all versions of the package in this tag except the latest
Test mode
Print details
Display help
SYNOPSIS
koji untag-build [OPTIONS] <tag_name> <build_name_or_id>
PARAMETERS
<tag_name>
The name of the tag from which the build should be removed. This is a required argument.
<build_name_or_id>
The name (NVR: Name-Version-Release) or ID of the build to untag. This is a required argument.
--rpm <rpm_nvr>
Untag only the specified RPM (by its NVR, e.g., 'mypkg-1.0-1.fc36') from the build. If this option is not used, the entire build is untagged from the specified tag.
--force
Force the untagging operation, bypassing certain dependency checks. Use with caution as it can lead to inconsistent states if not fully understood.
--user <username>
Specify the Koji username for authentication. If not provided, Koji typically attempts to use Kerberos credentials or a client certificate.
--password <password>
Provide the password for the specified Koji user. It's generally recommended to avoid passing passwords directly on the command line for security reasons.
--web
Authenticate using the Koji web interface, typically by opening a browser for login.
--debug
Enable debug output, providing more verbose information about the command's execution and any potential issues.
--quiet
Suppress most informational output, only showing errors or warnings.
--help
Display a help message for the untag-build subcommand and exit.
DESCRIPTION
The koji-untag-build command is a critical utility within the Koji build system, primarily used to dissociate a previously tagged build from a particular tag. In the context of Koji, a 'build' represents compiled software artifacts (like RPMs), and a 'tag' acts as a logical grouping mechanism, often corresponding to specific releases, branches, or development stages (e.g., 'f36-updates', 'rawhide').
The primary purpose of untagging a build is to rectify errors or manage release stability. For instance, if a faulty build was inadvertently tagged into a stable release, or if a build needs to be removed from a testing tag due to new issues, this command facilitates that removal. It does not delete the build itself from the Koji hub; rather, it simply severs the link between the build and the specified tag. This action prevents the untagged build from being included in future composes or installations that reference that specific tag.
CAVEATS
Untagging a build requires appropriate Koji permissions for the specified tag. Care must be taken, especially when using the --force option, as untagging builds can have cascading effects on dependent software or ongoing release processes. Untagging does not delete the build itself; it merely removes its association with a specific tag. Ensure you understand the impact before proceeding, particularly in production environments.
AUTHENTICATION METHODS
Koji clients support various authentication methods, including Kerberos, client SSL certificates, and web-based authentication (--web). Users typically configure their preferred method in the ~/.koji/config file. Using --user and --password directly on the command line is generally discouraged for scripts or shared environments due to security risks.
IMPACT ON COMPOSES AND REPOSITORIES
When a build is untagged from a tag that is used for generating software repositories (composes), the untagged build will no longer appear in subsequent repository generations. This effectively removes the software from being available via that particular distribution channel, which is often the desired outcome when an erroneous or problematic build needs to be pulled back.
HISTORY
Koji, developed primarily by Red Hat, has been the backbone of Fedora and Red Hat Enterprise Linux (RHEL) build systems since the mid-2000s. The untag-build command, like other core Koji client functionalities, has been an essential part of the Koji ecosystem from its early stages, evolving alongside the system's needs for robust build and release management. Its consistent presence highlights the enduring requirement for fine-grained control over which builds are associated with which release tags, crucial for maintaining software quality and release integrity.
SEE ALSO
koji tag-build(1), koji buildinfo(1), koji list-builds(1), koji block-build(1), koji edit-tag(1), koji regen-pkg(1)


