On Fri, Nov 27, 2020 at 4:43 PM El boulangero <elboulang...@gmail.com> wrote: > > I just finished packaging 20.10.0~rc1. It's still a WIP, but good enough for > upload to experimental. The package should be available in experimental soon. > Here are some links: > > - <https://salsa.debian.org/docker-team/docker/-/tree/experimental> > - > <https://buildd.debian.org/status/package.php?p=docker.io&suite=experimental> >
Thanks! > @Shengjing: For now the package still embeds containerd, as was the case with > docker.io 19.03.x. However it would be nice to remove this copy of containerd > from docker.io. [...] > So at the moment, if I want to COMPLETELY remove containerd from docker.io, > it means that either: > - containerd needs to backport these 3 patches, just so that docker.io can > build > - OR find a better solution (for example, revert patches in moby/buildkit so > that it can build against old containerd v1.4, but no, I tried, I don't think > it can work) > > If we go for this solution, I think that: > - it can work for debian bullseye (ie. stable), because after it's released > nothing will change much > - however for debian unstable, I think it could be trouble. Containerd 1.5 > will be released, then 1.6, and docker.io will lag behind and maybe require > more and more patching to build (unless containerd is very good at preserving > backward compatibility). > containerd's Go client hasn't been stabilized. See https://containerd.io/releases/#public-api-stability Upstream only promises the GRPC/Metrics/Runtime Shim/Daemon Config are stabilized, that's why docker upstream provides standalone containerd package. However the Go client will break from time to time, docker currently prefers using the master version. One of the docker maintainers says he prefers the tagged version of containerd, https://github.com/moby/moby/pull/41601#issuecomment-718275111 But it seems they fail to do that. > There is also another solution, a bit in the middle: docker.io keeps a vendor > copy of containerd (so that docker.io can patch its copy of containerd as > needed), but it uses this copy only for build time. For runtime, docker can > depend on the containerd package from Debian. > > My proposition would be: > - try to completely remove containerd from docker.io for now, so that it's > nice and clean for debian stable > - then during maintenance in debian unstable, if it becomes too much of a > mess, revert to vendoring containerd in docker.io, but only as a build dep > Yeah, that looks good. > What do you think of that ? Would you mind looking at > https://salsa.debian.org/docker-team/docker/-/commit/da70c7e, and tell me if > that makes sense to apply these patches in containerd ? Or do you have a > better idea ? > I will try to backport.
