- 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 https://yum.theforeman.org/releases/latest/el8/x86_64/foreman-release.rpm) containing the GPG key and yum’s
foreman-plugins.repo. Then there’s a
katello-repos RPM (like https://yum.theforeman.org/katello/4.5/katello/el8/x86_64/katello-repos-latest.rpm) which depends on
foreman-release (without a version) and adds
Additionally, there’s also a
foreman-client-release which is for the
The user is required to find the right combination to install. A mismatch can’t work. This adds a burden on users.
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
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 yum.theforeman.org. 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.