[Docker-maint] [pkg-go] Guidance for packaging Docker for Debian

Ian Campbell ijc at debian.org
Thu Mar 22 08:52:52 UTC 2018

On Thu, 2018-03-22 at 10:22 +0700, Arnaud Rebillout wrote:
> On 03/16/2018 04:43 PM, Ian Campbell wrote:
> >>>> In an ideal world, we should try to convince the docker people to use
> >>>> stable APIs (that means using only released non-alpha versions!),
> >>> FWIW the engine uses a non-alpha version in recent releases. It seems
> >>> to be swarmkit (another dep of engine) which is lagging and using the
> >>> alpha version (kind of interesting that that code seems to be ok when
> >>> vendored into moby but apparantly not when standalone, I suppose they
> >>> use different subsets of the API in different ways).
> >> Very interesting point indeed. For more details, here are the versions 
> >> of containerd vendored by docker:
> >>
> >> - docker-engine (ie moby): 3fa104f (after v1.0.0)
> >> - docker-swarmkit: 29a4dd7 (somewhere between v1.0.0 alpha3 and alpha4)
> >>
> >> Having both in sync would help for sure.
> > I prodded some folks yesteday a lo:
> >     https://github.com/docker/swarmkit/pull/2560
> Hey Iann, I noticed that the pull request you mentioned was merged
> yesterday in Docker Swarmkit.
> So I gave it a try today, I updated my swarmkit package and tried to
> build against the latest stable version of containerd, `1.0.2` at the
> time of this writing. Of course, it didn't work ;)
> Swarmkit wants parts of the containerd API that don't exist, and it
> started giving me a headache, until I realized what's going on.
> Containerd has a branch 'release/1.0', and that's where the stable
> version 1.0 is developed. However, Docker vendors a commit from the
> branch 'master', ie. where the unstable version lives. So, even though
> this commit is after '1.0', it contains some part of the API that will
> be released in containerd '1.1' I guess, and therefore I'm stuck again
> with the same choice: either I package a specific version of containerd
> for docker, either I wait for a '1.1' release of containerd, in the hope
> that Docker can build against it. But it's very likely that it won't
> because containerd will be too new then, so I will have to wait for
> Docker to update its vendoring bits, and so on, a hopeless and endless
> cycle.
> So, in short, it's great that containerd tags its release and has a
> stable branch, but it's too bad Docker doesn't use it...

I wasn't aware of that, how strange. I suppose the rationale is that
v1.1 will be upwards compatible with v1.0, but still...

I'll mention this to some folks internally and see what, if anything,
can be done.


More information about the Docker-maint mailing list