On 6/11/19 9:25 AM, Dmitry Smirnov wrote: > On Monday, 10 June 2019 3:03:23 PM AEST Arnaud Rebillout wrote: >> I also want to try to unbundle >> containerd from the docker package, > This may be very risky to do so one have to have a good justification what > those risks are taken for. > > It has been attempted in the past with disastrous results. Containerd is used > by Docker (exclusively?) and with very specific vendoring. With current > upstream culture of incompetence in regards to versioning, another attempt to > ship containerd separately is likely to fail. Unbundling containerd should be > considered very very carefully with full understanding of why burning effort > for the attempt. > AFAIU there's two issues:
1. the fact that docker uses snaphots of containerd. 2. the fact that both docker and containerd vendor each other, leading to unbreakable circular dependencies. For issue 1, I would have a the docker releases accross the last year, and see what version of containerd they use. If it happens that they consistently use releases of containerd rather than snapshots, then maybe we can consider that issue 1 is gone (but it's true that they're no warranty that they won't go back to using snapshots later down the road....) For issue 2, I would try to have a look at what they vendor from docker, once again over a one year time span, and try to assess it they're doing any progress un-bundling docker parts from containerd, or not. I've seen in Shengjing Zhu's containerd package that there is still some vendoring of docker parts, so I don't think it's solved yet, but maybe it's on the way. Even if these two points are solved, it's true that there's a risk that it comes back, even more both projects have more or less the same upstream. I'm not really aware of who develop what, and if both projects are really developed separately, or by the same group of people.