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.


I have just forked a new Redmine issue to track this: Feature #35348: Introduction of a new katello-release RPM - Packaging - Foreman

On the technical (install) side: there is also dnf swap which e.g. CentOS used to replace centos-linux-release with centos-stream-release.

And a question: Would the resulting RPM then live only in the Foreman repo, or cross-tagged to Katello too? The later allows for dnf install so the user is only concerned about the Katello version they are installing, as otherwise they would still need to know the “matching” Foreman version (but have no possibility to mix the two up).

I think, from a project perspective, the Katello version shouldn’t play a such “big” role and users and docs should orient on the Foreman version, but at the same time I am not sure how easy that would fit into users minds?

Good point.

I don’t think that’s needed. Instead we should starting using Foreman versions. That implies a Katello version, just like a Foreman version also implies REX x.y.z (because it’s in foreman-plugins-x.y) but users shouldn’t care too much about it.

Agreed and already starts to take that approach. URLs only use the Foreman version.