On Mon, Jan 6, 2020 at 11:31 AM Arnaud Rebillout <arnaud.rebill...@collabora.com> wrote: > > Hi Shengjing, > > > > I think nowadays the docker upstream has much improvement on the > dependencies versions. > > there are two things that prevent the docker.io package to depend on the > containerd package. > > > ---- 1st issue: versions ---- > > On the branch `19.03`, docker vendors containerd as such: > > github.com/containerd/containerd 7c1e88399ec0b0b077121d9d5ad97e647b11c870 > https://github.com/containerd/containerd/commit/7c1e88399ec0b0b077121d9d5ad97e647b11c870 > > > which is somewhere on the master branch (date: 08-05-2019), and after > the tag v1.2.0. > > On the branch `master`, docker vendors containers as such: > > github.com/containerd/containerd acdcf13d5eaf0dfe0eaeabe7194a82535549bc2b > https://github.com/containerd/containerd/commit/acdcf13d5eaf0dfe0eaeabe7194a82535549bc2b > > which is somewhere on the master branch (date: 14-10-2019), and after > the tag v1.3.0. > > Docker never tried to settled on a tag of containerd, and I see that to > this date it's still true: docker will just vendor whatever containerd > commit from the master branch. > > For Debian packaging it's obviously an issue, because you will package a > specific tag of containerd, and then it's likely docker won't build > against it, and we'll have to do some desperate patching to make the > pieces fit together (last time I looked into it, the patching involved > was not trivial). >
Oh, there's still some mess. I think I can work with upstream (at least) to use containerd release/1.3 branch for next release. But I think generally upstream has managed to use released containerd version, at least in their deb/rpm repo. (IIRC they have built containerd separately last year or so.) https://download.docker.com/linux/debian/dists/buster/pool/stable/amd64/ You can see containerd-1.2.10 things. > > ---- 2nd issue: circular dependencies ---- > > I'm not sure how much it's still true, but the last time I looked into > it, there was some non-trivial circular dependencies between both > packages, making it impractical, or impossible, to package both separately. > > Do you know if containerd still build depends on Docker these days? If > so, how much of docker codebase is pulled in? > > 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). In the src:containerd/experimental, I kept docker/docker in vendor to avoid circular problem. https://salsa.debian.org/go-team/packages/containerd/tree/master/vendor/github.com/docker -- Shengjing Zhu
