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

[Ian Campbell]

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.

Ian.