Introduction of a new katello-release RPM

Short summary:

  • A new RPM katello-release will be created in the Foreman repo
  • katello-release will obsolete katello-repos
  • katello-release will conflict with foreman-release


Today we have a foreman-release RPM (like containing the GPG key and yum’s foreman.repo and foreman-plugins.repo. Then there’s a katello-repos RPM (like which depends on foreman-release (without a version) and adds katello.repo.

Additionally, there’s also a foreman-client-release which is for the foreman-client repository.

The Foreman repositories follow Foreman’s version number (like /releases/3.3 and /plugins/3.3) while Katello repos use Katello’s version number (like /katello/4.5).

The user is required to find the right combination to install. A mismatch can’t work. This adds a burden on users.

Introducing a new katello-release RPM package

The new RPM package will contain all the needed .repo files. This means users can’t mismatch anymore.

To reduce maintenance efforts, it is proposed that it becomes a subpackage of foreman-release. There we already have all the needed files, removing the need to duplicate them. It is painful to publish a subpackage from to a different repository, so it is easier if we publish the package in the Foreman repository, just like we publish foreman-installer-katello there already.

It should obsolete katello-repos with a version constraint that depends on the branch. For example, katello-release-3.4.0 (which brings Katello 4.6) should obsolete katello-repos < 4.7.

On a technical level foreman-release and katello-release should conflict with each other. This does mean migration for existing katello users can be harder. An obsoletes on older foreman-release versions may result in existing foreman users getting the katello release file instead. The upgrade instructions can suggest dnf install --allowerasing which means DNF can do the swap for the user. The alternative is an explicit removal. This should be verified in practice.

Additionally, we have code to maintain the foreman-release.rpm symlink (which points to the latest version). This should be enhanced to also deal with katello-release. The code for that is here:


This does not change the structure on Changing that takes more time and introducing a new katello-release RPM is a quick win. Additionally, if the repositories do change in the future, this change makes it easier because the installation instructions won’t change.

Users syncing the repositories themselves (for offline access or otherwise) still need to match up versions. For them this is no solution. However, they can read the files in katello-release so see which repositories they need to sync.


Due to priorities we will only start this work after Foreman 3.4 has been branched. This means it will be unlikely to land in RC1, but it can be included in RC2. If this works well, it can even be introduced in stable branches, but initially that’s considered out of scope.