If contianerd needs a special version of runc, then it should put its version of runc into a private directory and use it from there. Conflicting with the default runc is causing other packages to fail to be able to be installed.
How does this package relate to the moby packages?
The above is based on a question I asked on the Fedora test list, trying to understand the relationship between the packages "runc", "containerd" and "containerd.io", which appear to conflict with one another. First, it would appear that containerd.io "provides" all three names: $ rpm -q --whatprovides runc containerd.io-1.2.4-3.1.fc29.x86_64 $ rpm -q --whatprovides containerd containerd.io-1.2.4-3.1.fc29.x86_64 $ rpm -q --whatprovides containerd.io containerd.io-1.2.4-3.1.fc29.x86_64 Unsurprisingly, only the containerd.io package is installed: $ rpm -q runc package runc is not installed $ rpm -q containerd package containerd is not installed $ rpm -q containerd.io containerd.io-1.2.4-3.1.fc29.x86_64 Predictably, trying to install runc produces: $ sudo dnf install runc [sudo] password for rpjday: Last metadata expiration check: 0:42:25 ago on Fri 29 Mar 2019 07:05:12 AM EDT. Package containerd.io-1.2.4-3.1.fc29.x86_64 is already installed. ... snip ... Weirdly, "dnf repoquery -l <packagename>" lists the contents of the "containerd" package but not "containerd.io" which seems the opposite of the above. Others are welcome to untangle these three packages, if that's what seems necessary. Oh, for what it's worth: $ rpm -q --whatrequires runc cri-o-1.12.0-12.dev.gitc4f232a.fc29.x86_64 buildah-1.7-17.dev.git146a0fc.fc30.x86_64 podman-1.1.2-2.dev.git0ad9b6b.fc30.x86_64 $ rpm -q --whatrequires containerd no package requires containerd $ rpm -q --whatrequires containerd.io no package requires containerd.io I'm not sure if the above is significant.
The containerd.io package comes from the Docker CE repo. The Fedora package for containerd does not ship it's own runc or conflict with runc from Fedora. In fact it requires runc. # repoquery --quiet --info containerd Name : containerd Version : 1.2.4 Release : 1.fc31 Architecture : x86_64 Size : 19 M Source : containerd-1.2.4-1.fc31.src.rpm Repository : rawhide Summary : An industry-standard container runtime URL : https://containerd.io License : ASL 2.0 Description : containerd is an industry-standard container runtime with an emphasis on : simplicity, robustness and portability. It is available as a daemon for Linux : and Windows, which can manage the complete container lifecycle of its host : system: image transfer and storage, container execution and supervision, : low-level storage and network attachments, etc. # repoquery --quiet --list containerd /etc/containerd /etc/containerd/config.toml /usr/bin/containerd /usr/bin/containerd-shim /usr/bin/ctr /usr/lib/.build-id /usr/lib/.build-id/08 /usr/lib/.build-id/08/ad865a04b14d74bd98f7c290f4a8d790d73f82 /usr/lib/.build-id/64 /usr/lib/.build-id/64/d1a074140ba554903b4ab14f488c5ed087d4b0 /usr/lib/.build-id/c2 /usr/lib/.build-id/c2/a2af005c0fb5e7cd044ec736f8776f030d9ce1 /usr/lib/systemd/system/containerd.service /usr/share/doc/containerd /usr/share/doc/containerd/README.md /usr/share/licenses/containerd /usr/share/licenses/containerd/LICENSE /usr/share/man/man1/containerd-config.1.gz /usr/share/man/man1/containerd.1.gz /usr/share/man/man1/ctr.1.gz /usr/share/man/man5/containerd-config.toml.5.gz # repoquery --quiet --conflicts containerd # repoquery --quiet --requires containerd | grep runc runc Ideally moby-engine should require containerd and runc instead of shipping it's own versions. # repoquery --quiet --list moby-engine | grep -e containerd -e runc /usr/bin/docker-containerd /usr/bin/docker-containerd-ctr /usr/bin/docker-containerd-shim /usr/bin/docker-runc
Ah, now I get it. I guess I had containerd.io installed from when I was still pulling from the Docker repos, and didn't realize it. At this point, does one need Docker repos configured at all?
Only if you want packages directly from Docker, Inc.
Carl, sorry about the noise.
Same here, sorry for my being unaware of where I had gotten that package from. And as for Dan's last reply about the Docker repo, I phrased that question badly. What I was asking was, given the plethora of Fedora packaging of container stuff, is there any *need* for Docker repo packages, unless of course you're wanting to do something clearly Docker specific? As in, can you get all the industry-standard container technology you might need from the Fedora repos, and stop using Docker repos entirely? Thanks for your patience.