On Mon, Jan 6, 2020 at 3:02 PM Arnaud Rebillout <arnaud.rebill...@collabora.com> wrote: [...] > Thanks for the details. So if I understand properly, the situation for > upstream docker is that: > > - the build dependency is against a containerd commit from the master branch > (pulled in according to the vendor.conf file) > - however for runtime, docker-ce depends on an external containerd.io > package. The version of this package suggests that it's a released version > and not a snapshot. > > Do you understand the same? >
Yes. > Maybe we could try a similar middle ground for our packaging, ie. build with > the vendored copy of containerd, but don't ship the containerd binary, and > instead depend on the containerd package. > > But if we want this to work, I guess we should stick to the versions that are > tested by docker upstream, which might be an issue (if you want to track > latest containerd and docker lags behind, what do we do?). > We should keep containerd version in sync with docker. eg docker 19.03.x with containerd 1.2.x. And I guest next docker major version will use containerd 1.3.x. > Talking about versions, looking at the file > https://download.docker.com/linux/debian/dists/buster/stable/binary-amd64/Packages, > I can see that: > > - the docker-ce package started to depend on container.io from the 18.09.x > series (it's been a while: good) > - the latest version of docker-ce "5:19.03.5~3-0~debian-buster" depends on > containerd.io (>= 1.2.2-3)... Where is the source for this package? Is > containerd.io patched here? > > I found a comment from someone asking for the sources of the package: > https://github.com/containerd/containerd/issues/1508#issuecomment-461413010. > The comment went unanswered. A bit more research, and still no idea where are > the source for this package. Do you have an idea? > Neither do I :( But let's be optimized about this. There's no reason for docker upstream to _hide_ some patches which are not applied in containerd upstream :) Actually if you look at commits in containerd release branch, the people from docker are actively backporting things. > That sounds like a red flag if we don't know what patches (if any) are > applied to the containerd.io package shipped by docker in their repo. > > > containerd(without cri) don't import github.com/docker/docker. > But containerd-cri needs some functions from docker repo. > But you can build containerd with no_cri tag(I think this should be > used when building docker, next release). > > > Ok, good to know. Does that mean that you would build containerd with > `no_cri`, so that the containerd-dev package would not depend on docker-dev? > (I have no idea what CRI really does and if it's needed in Debian). > CRI makes containerd useful without docker in a kubernetes worker node. (That's why I want a separate containerd package) I have some mistakes in my previous sentence. It should be, + github.com/containerd/cri pull in github.com/docker/docker. + github.com/containerd/containerd/cmd/containerd pull in github.com/containerd/cri So only when you build containerd binary(with cri), you will need github.com/docker/docker. No consumer will pull in github.com/containerd/containerd/cmd/..., so no need to pull in github.com/docker/docker. There's no circular dependencies, apparently. -- Shengjing Zhu
