Arnaud, In my experience the most helpful resource when building go packages has been #debian-golang on irc.debian.org. I’d recommend hopping in there with questions. I’ll make an effort to be in there as much as possible to help where I can.
Stephen On Tue, Feb 13, 2018 at 3:44 AM, Arnaud <arnaud.rebill...@collabora.com> wrote: > Dear Docker Packaging Team, > > I'm working at Collabora, and right now I have a bit of time to dedicate > to the Docker Debian package. I would like to bump Docker to the latest > version in Debian unstable. > > Up to now I've been struggling a bit to get the big picture, and I think > I'm getting there. > > From what I understood from the latest `vendor.conf` file, Docker now > uses runc and containerd from upstream. Moreover, I cooked a little > script to compare the vendored libraries with their upstream version, > and amazingly it looks like Docker doesn't patch any of its vendored > libraries at the moment. Same goes with containerd. > > It seems that it was not so simple in the past, and that's why there is > now a 'docker-runc' and a 'docker-containerd' package. But in this mail > I won't talk about these packages, I'm interested in the 'runc' and > 'containerd' packages which track the upstream repositories, not the > docker forks. > > So what I want to do in a first step is to bump the 'runc' and > 'containerd' package to the latest version. It seems that the 'runc' > package is already up-to-date (1.0.0-rc4). However the 'containerd' > package is still at '0.2.3', while upstream is at '1.0.2-rc1'. > > I looked at the situation, and there's a bit of work involved: a little > less than 20 packages need to be created or bumped to a newer version. I > already created 4 packages that I submitted through ITP and that are now > available on salsa.debian.org. > > So in the following days and weeks, I will hopefully dedicate some time > to package containerd dependencies, until I manage to get containerd > itself packaged and up to date. Then I will attempt the same with the > docker package. At least, that's the plan :) > > Tell me if I miss anything ! > > Additionally, I noticed that since mid-2017, Docker changed the way it > manages its codebase. There's now 3 repo: > > - https://github.com/moby/moby for the engine > - https://github.com/docker/cli for the client > - https://github.com/docker/docker-ce which is a kind of > "meta-repository" that contains both repositories above, plus packaging > files. > > The tricky thing is that the engine and the client don't get tagged > anymore, only docker-ce has tags and releases. > > I don't know if some of you already dived into this. It seems to me that > it could be easier to have two packages: docker-engine that would track > moby/moby, and docker-cli that would track docker/cli. Then a > metapackage 'docker' that would depend on both, and ensure the versions > match. > > On the other hand I'm quite new at Debian packaging, so I wouldn't trust > myself :) > > What's your thoughts on that ? Any comment is welcome. > > Best regards, > > Arnaud > > _______________________________________________ > Pkg-go-maintainers mailing list > Pkgfirstname.lastname@example.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers _______________________________________________ Pkg-go-maintainers mailing list Pkgemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers