On 03/15/2018 08:42 PM, Ian Campbell wrote:
On Thu, 2018-03-15 at 12:52 +0000, Martín Ferrari wrote:
I sometimes have kept small dependencies vendored in for
convenience..
But keeping the whole containerd seems wrong to me.
OTOH it _might_ not be totally unreasonable to apply that tactic to
swarmkit which in essence has a single consumer (docker engine).
That's a good point. Here's the dependency tree that bothers me right now
docker-engine
\_ golang-github-docker-swarmkit
\_ golang-github-docker-libnetwork
The main problem here are the circular dependencies, since both swarmkit
and libnetwork import bits from docker-engine. To avoid the circular
dep, I vendor docker-engine within swarmkit and libnetwork. But it
doesn't work, because I end up with duplicated bits that are not
compatible, as described in
<https://github.com/Masterminds/glide/issues/73>.
To be more specific, both import 'pkg/plugingetter', and the build fails
with this error:
have Get(string, string, int)
("github.com/docker/swarmkit/vendor/github.com/docker/docker/pkg/plugingetter".CompatPlugin,
error)
want Get(string, string, int)
("github.com/docker/libnetwork/vendor/github.com/docker/docker/pkg/plugingetter".CompatPlugin,
error)
Actually, this 'pkg' directory is the main cause of circular
dependencies, and hence it's a big pain point. From the README that you
can find in moby/pkg:
"pkg/ is a collection of utility packages used by the Docker project
without being specific to its internals."
These utilities are useful outside of docker, and that's why every other
docker projects include docker-engine and fish into the pkg directory.
Hence the circular dependencies.
If we could somehow package this directory as a library, separately from
docker, then we would have much less circular dependencies. But since
this directory is definitely not something stable, that will also bring
us deeper in an "unresolvable dependencies hell".
So how to solve that ?
One easy solution would be to stop packaging swarmkit and libnetwork,
and just vendor it in docker-engine. Of course, that makes sense only if
there's no other consumers for these libraries.
The other solution (for me) is to learn more about Go and the way they
handle this problem of duplicated vendored bits, and then transpose this
solution somewhere in the debian packaging files.
It's also possible that I just do it something wrong somewhere, and I
didn't figure it out yet.
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.
However after giving it a closer look, I think I could patch swarmkit to
build against containerd v1.0.0. Maybe it's not so hard.
I think now that containerd v1.0.0 is out and given the stated API
guarentees containerd is making[0] the problem will be less bad in the
future at least wrt this particular set of components since there
ougtn't to be build breakage from using a "too new" version of
container within a given major release series.
I hope you're right :)
Regards,
Arnaud
_______________________________________________
Pkg-go-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
