[pkg-go] News on docker packaging, the work is in progress

[Johannes Schauer]

Hi all,

Quoting Michael Stapelberg (2018-04-18 23:24:06)
> > - there's always this problem of circular dependencies, ie. all these
> > Docker dependencies that depend on Docker. I can't have them depend on
> > Docker because the Docker package is outdated and fails the build. So
> > right now I vendor. How to solve that? I didn't have any genius idea
> > here, the only solution I see would be to create a package
> > `golang-github-docker-docker-dev` that is different from the `docker.io`
> > package (ie. another source package), and that just ships the docker
> > bits that are used by other packages. Having a different source package
> > would solve the circular dependency problem.
> I think josch (cc'ed) either has experience in this area or knows who might
> be able to answer this.

I'm not familiar with the docker ecosystem and I don't know whether the
"packages" you talk about are source or binary packages or whether the
"dependencies" you talk about are build or runtime dependencies, but in
general:

If you have a situation like this:

   src:A --> B ==> src:B --> A ==> src:A

Where --> is a build dependency and ==> is a builds-from relationship.

In the context of bootstrapping you would break this cycle by either

 - building src:A without B or src:B without A using build profiles
 - cross-compiling either src:A to produce A or src:B to produce B
 - maybe B is actually a Build-Depends-Indep of src:A or A of src:B?
 - splitting src:A or src:B such that they produce A or B without
   build-depending on B or A, respectively

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20180418/ac21079d/attachment.sig>