On Fri, Apr 8, 2016 at 7:18 AM, Antonio Murdaca <amurdaca redhat com> wrote:
Yes, that was what I initially thought Mruanl - not sure we could ship those docker-* subpkgs though but that would definitely fix this issue since we'll ship specif versions of those tools *with* docker. However, as Dan pointed out in the Trello card those binaries should be _hidden_ under /usr/libexec/docker for instance.--On Fri, Apr 8, 2016 at 4:14 PM, Mrunal Patel <mpatel redhat com> wrote:I think if allowed, then we should atleast ship a newer version of runc as a separate package. The one that docker needs could be shipped with the docker package as docker-runc. (We could do the same for containerd if we expect usage of it outside of docker.)Thanks,MrunalOn Fri, Apr 8, 2016 at 6:04 AM, Daniel J Walsh <dwalsh redhat com> wrote:In docker-1.11 docker is going to be using a new daemon, containerd, as well as runc. However docker is forcing a link between containerd and runc. During the building of docker, docker is actually pulling the containerd and runc packages currently installed on the box and check summing them. Then docker refuses to run unless these exact versions of containerd and runc are installed on the box. Docker does change the name of these executables to docker-containerd and docker-runc.
As we look to package these tools for Fedora, Centos and RHEL, we have to decide whether or not we want to package multiple versions of runc so that we can develop these at different rates or lock the versions together as docker wants. We could patch out the checksum check and rely on rpm to make sure the current version of docker has a late enough version of containerd and runc, to be supported.
Not sure what the policies of Fedora and Centos to have multiple versions of basically the same executable installed on the system at once.
Dan
Antonio MurdacaIRC: runcomGPG: 0DE936B9