Moby packages in packages-microsoft-com-prod conflict with Docker CE on RHEL 9 (moby-cli obsoletes docker-ce)

[jasonheffnerpsu]

Summary

A recent update to the packages-microsoft-com-prod repository introduced
Moby packages (e.g., moby-cli, moby-engine) that now declare:

• Conflicts: docker-ce
• Obsoletes: docker-ce

This is new behavior. As a result, systems that use Docker CE on RHEL 9 /
Rocky 9 / Alma 9 can no longer perform dnf upgrade or install
docker-ce-related packages if the Microsoft repo is enabled — even though
Moby is not installed.

---

What Happens

With the Microsoft repo enabled:
sudo dnf upgrade

fails with errors such as:

Problem 1: package docker-ce-rootless-extras-29.1.2-1.el9.x86_64 from @System requires docker-ce, but none of the providers can be installed

• package moby-cli-29.1.2-1.el9.x86_64 from packages-microsoft-com-prod conflicts with docker-ce provided by docker-ce-3:29.1.2-1.el9.x86_64 from @System
• package moby-cli-29.1.2-1.el9.x86_64 from packages-microsoft-com-prod obsoletes docker-ce provided by docker-ce-3:29.1.2-1.el9.x86_64 from @System

Simply having the repo enabled causes this conflict.

Expected Behavior

Moby packages should be installable as an alternative runtime, but should
not forcibly replace or conflict with Docker CE unless the user explicitly
chooses to install Moby.

---

Impact

Many systems rely on this repo for Azure CLI or .NET. After the recent
change, these systems must now disable the entire Microsoft repo or add
manual excludes just to use Docker CE.

---

Request

Could the Conflicts: and Obsoletes: rules for docker-ce be reviewed
or relaxed so both repositories can coexist again?

[garretwyman]

Hi @jasonheffnerpsu, we (the package.microsoft.com team) own and maintain the infrastructure and don't maintain individual packages. I've transferred the issue internally to the appropriate team.

[cpuguy83]

Investigating this.
It looks like the older packages were not including conflicts/obsoletes as expected and as such been "working" all this time.
For the 29 packages we've moved to a new build pipeline and these values are now being set as was the original intent but of course causing this issue now.

Testing out a solution and will plan to have an updated package today.

[cpuguy83]

The bad packages have been removed and should resolve the particular issue.

We also have changes pending to remove that conflicts/obsoletes metadata from the new builds.

[Klaas-]

The same thing happened a couple of years(?) back, I had to complain via support ticket. I am guessing no one thought to built a QA test for this, maybe do that now so it doesn't come back next time you change build pipelines? :)

[jasonheffnerpsu]

Much appreciated, I didn't expect as quick of a response and resolution. I know these integration pieces can be difficult. Thanks!

[reneleonhardt]

As a side note, can the Moby packages be added to Debian 13 (Trixie), which are still available for Debian 12? 😄
devcontainers/features#1442 (comment)
https://packages.microsoft.com/debian/13/prod/pool/main/m/
https://packages.microsoft.com/debian/12/prod/pool/main/m/

• moby-buildx
• moby-cli
• moby-compose
• moby-containerd
• moby-engine
• moby-runc
• moby-tini