[pkg-go] docker, consul, notary and others
Tianon Gravi
tianon at debian.org
Mon Mar 7 17:25:46 UTC 2016
On 6 March 2016 at 14:47, Dmitry Smirnov <onlyjob at debian.org> wrote:
> I'm working hard to update dependencies required by new version of docker.
> If that's all right with you I'd like to join you as co-maintainer of consul,
> notary, docker.io and some other packages.
Getting more eyes on the packages sounds reasonable, and should help
get deps faster. :)
> Consul 0.6.3 is currently waiting for "go-memdb" blocked by another package
> in NEW; notary 0.2.0 is waiting for bugsnag blocked by revel/NEW and for
> docker-distribution 2.3.0 is OK; libnetwork is almost finished and should be
> ready for upload as soon as we introduce consul (can I, can I ;).
>
> I'm contemplating idea of uploading older version of consul, just to speed
> things up.
Sounds reasonable to me -- it was basically ready last I looked, just
needed review and upload.
Is "libnetwork" finally abstract enough that it can be used without
"docker/docker" ? I think we've been shipping "src:docker.io" as
multi-orig up until now specifically just for this last holdout that
was too deeply integrated to package separately, so I'd love to be
able to remove that complication!
> Also I think we should upload notary with bundled "github.com/docker/docker"
> (to avoid circular dependency on docker) and with bundled "github.com/docker/
> go" as the latter does not look like a good candidate to be shipped in its
> own package.
This is tricky territory, I think. Policy 4.13 is the relevant
section we'll need to be careful about
(https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles),
which does talk about "unless the included package is explicitly
intended to be used in this way" (giving us some kind of leeway here)
but in this case I don't think Notary is intended to be the only
consumer of this code, is it? Would it be legal/make sense (within
the confines of policy and good practice) to split
golang-github-docker-docker-dev out from src:docker.io to help resolve
these conflicts?
(I've added the relevant groups to CC here so that we can hopefully
get a bit of further comment on this front, since I'm sure Docker and
friends won't be the last Go packages to have this kind of issue.)
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
More information about the Pkg-go-maintainers
mailing list