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 <mpa...@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, > Mrunal > > On Fri, Apr 8, 2016 at 6:04 AM, Daniel J Walsh <dwa...@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 Murdaca IRC: runcom GPG: 0DE936B9
