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.
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:
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.
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.
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.
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.