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).
---- 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?
> So if you like the option a, I could help move the current
src:containerd from experimental to unstable
Is there anything that blocks you here? I indeed like option a: if
there's a containerd package in debian, it should be build from
src:containerd. The fact that docker embeds its own copy shouldn't
prevent you from providing a containerd package.
I'm not quite sure that we nailed down the Replaces/Breaks/Conflicts
that are needed though, we might need to work a bit on that.
At the moment, the docker package installs containerd as
`docker-containerd`, and uses this binary, so I *think* that both
containerd and docker could be installed in parallel. That's why there's
no Breaks/Conflicts for those packages. I don't think this was tested
though.
We also have this in the docker.io package:
Replaces: golang-github-containerd-containerd-dev
Breaks: golang-github-containerd-containerd-dev
Provides: golang-github-containerd-containerd-dev
So basically, it means that a package that Build-Depends on
golang-github-docker-docker-dev will pull in docker's version of
containerd-dev.
All in all, the idea is that docker.io shouldn't block anyone from
packaging containerd. I wish that the docker.io package could depend on
containerd, instead of vendoring it. But as long as the two main issues
mentioned above are not solved upstream, there's little chance we'll
solve it in Debian.
Cheers,
Arnaud
On 1/5/20 7:28 PM, Shengjing Zhu wrote:
Source: docker.io
Severity: wishlist
Hi Dmitry Smirnov and Arnaud Rebillout,
I would like to have a standalone containerd package. Containerd has
CRI(Kubernetes Container Runtime Interface) support[1].
This makes it possible to run containerd alone without docker, eg on a
Kubernetes node[2]. And I don't need features like `docker build` in
this scenario.
Would you like to:
a. build a separate containerd package from src:containerd
b. build a separate containerd package from src:docker.io
I think nowadays the docker upstream has much improvement on the
dependencies versions. So a separate src:containerd makes sense. I
checked the docker-ce repo, it has pull containerd 1.3 to its master.
So if you like the option a, I could help move the current
src:containerd from experimental to unstable, when the next docker
major release happens. (of course, the version of containerd should
sync with the docker release.)
[1] https://github.com/containerd/cri/
[2]
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/
