On 1/6/20 12:41 PM, Shengjing Zhu wrote:
I think I can work with upstream (at least) to use containerd
release/1.3 branch for next release.
That would be awesome!
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.
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?
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?).
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?
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).
Cheers,
