Cleanly uninstalling packages during upgrades


with the recent drop of the *_core packages (foreman_remote_execution_core, foreman_ansible_core, etc) we ended up in a situation where users who upgrade from a previous release end up having the old (unused) *_core package still installed.

We first tried to fix that by adding an Obsoletes to the corresponding smart_proxy_<plugin> package, but that turned out to be wrong (for details see the discussion in Katello-nightly-rpm-pipeline 1022 failed and Do not Obsolete foreman_remote_execution_core from smart_proxy_remote_execution_ssh by ehelms · Pull Request #6861 · theforeman/foreman-packaging · GitHub) and we reverted that change again.

However, the fact that users end up with the old core package still installed also means that if that package has any dependency constrains, these must be honored by yum/dnf. Which brings me to the source of this post: foreman-plugins-nightly-rpm-test-pipeline #8 [Jenkins] is red because the old foreman_ansible_core is still installed and yum can’t upgrade:

    Error: Package: tfm-rubygem-foreman_ansible_core-4.1.0-1.fm2_5.el7.noarch (@foreman-plugins)
               Requires: tfm-rubygem(foreman-tasks-core) < 0.4
               Removing: tfm-rubygem-foreman-tasks-core-0.3.5-1.fm2_5.el7.noarch (@foreman-plugins)
                   tfm-rubygem(foreman-tasks-core) = 0.3.5
               Updated By: tfm-rubygem-foreman-tasks-core-0.4.0-1.fm2_6.el7.noarch (foreman-plugins-koji)
                   tfm-rubygem(foreman-tasks-core) = 0.4.0

Thus we need a safe way to purge these old core packages. On EL7 we could abuse the tfm package, but on EL8 there is no such thing.

@ekohl proposed to introduce a foreman-obsolete-packages (or similar, like Fedora has) that should be used for that. I like the idea.

Essentially that’d be an empty package, with Obsoletes for all ecosystem related obsoletes (dropped plugins etc).

What about y’all?

esp @aruzicka @ehelms @pcreech @Odilhao @Zhunting


Another question that comes up: is foreman-tasks-core even still needed, or did we just forget to nuke it?

I think the above issue would go away if f-t-core is gone, so yum doesn’t try to update it, but cleaning up our mess is still a good thing to do.

Having a dummy package for obsoleting others feels like the way to go. Iirc I’ve seen some linux distributions employing this approach to deal with dropped packages.

Otoh, it is slightly confusing if you don’t know what’s going on to see something like “Updating foreman-obsolete-packages” in a yum/apt log.

How would this work on debian? Does deb packaging have a equivalent for rpm’s Obsoletes?

Alternatively we could turn all the *-core packages into empty ones, no dependencies, no content.

It can be dropped.

One thing I didn’t think about until now is whether we should move old obsoletes:

I think partially yes, but also partially no. In case it’s really only from our ecosystem (like Foreman (Proxy) plugins) then it makes sense. However, for gems it may not. We are the only user of the tfm- “namespace” but in case of EL8 it can be shared. Some other tool may also require a package like rubygem-mygem. It does mean we may end up with more orphaned packages on EL8 but IMHO that’s something DNF should deal with.

Yeah, I think foreman-obsoletes should only touch things that are explicitly ours, like rubygem-foreman_*, or rubygem-smart_proxy_* etc.

Others should be kept in tfm and in the case of EL8 left as an exercise to the user.

1 Like

Will it be one package for the whole ecosystem or one for foreman and one for smart-proxy? Could be confusing if a system has only a smart proxy installed and it sounds like the package is in the foreman naming schema, but I am only thinking loud and it could also be no problem.

Yes and no.

In RPM land, “package A obsoletes package B” means that if the user had package B installed, and yum/dnf see package A in the repo, it will remove package B and install package A. Even if package A was not installed before.

In DEB land, you can say “package A breaks and replaces package B”, which will mean package B will be uninstalled if (and only if) package A is installed/upgraded (on user request).

That said, we’ve not been (historically) cleaning up much on Debian, but we probably could.

Well, the proxy package is called foreman-proxy, so I see not too much (new) confusion there.

I would prefer one package for everything, especially as the problem at hand is with the “core” packages which always were a bit of a hybris between Foreman and Proxy.


I’m all for the foreman-obsoletes package. I took some time to try to figure out options, and this is the best one I can find.