Re: Dealing with go dependencies in recipes - native docker-compose

Bruce Ashfield

On Tue, Oct 18, 2022 at 9:17 AM Bruce Ashfield via <> wrote:

On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke <konstantin.kletschke@...> wrote:
On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:

> FYI: Here's the very lightly tested RFC version of the recipe:

Thanks for the kind notification.

My stuff is based upon kirkstone, I stuffed the recipe from master-next
into my kirkstone build. One package of this new docker-compose is depending
upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
langdale also into my kirkstone build.

The compiling and building works just fine! The recipe(s) for
docker-compose look impressive, I would not have expected them being so
complex. But they work.

The amount of fetches is certainly impressive, but it is like that for any non-vendored go application, whether we can see it or not.  When the recipes are simple, all of the fetching and source structuring takes place behind the scenes (I know, I'm stating the obvious), just in a manner we don't control.

I just yank the complexity out to the front, and go directly to the upstream sources of all the go libraries/packages. If we let go fetch it, we have to both rely on the versions being in the fetch locations "forever", or the infrastructure always being available (it should, but you never know). We then have to setup our own go proxy/mirror infrastructure to get around those two issues, and have now become curators of our own repositories and infrastructure. That infrastructure isn't really hard to setup, but in a maintenance mode, updating it, and getting new versions of the code for CVEs, etc, could be challenging.

By doing the fetches directly, all of the established infrastructure, archiving, mirrors, licensing, etc, "just work", and we can bump the SRCREV of any dependency if a CVE or issue is found.

Definitely a balancing act, with no 'one true answer' yet, so I've been going with what I know works :)

Two notes:

After installing the package provides /bin/docker-compose. I realized
other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
which make something like "docker compose version" working. For me this
does not harm, only as remark. May be this is intentional.

Completely random. I just put it there. I'll make that adjustment in the recipe.

Upon investigating I realized the version reported by docker-compose is
"dev" instead of the expected "v2.11.2".

I saw the same thing, and was looking into fixing it, I figured it was worth getting the recipe out, before I did more tweaking.

emux86-64-c9 login: root

root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version

Docker Compose version v2.11.2




Great work, thank you!

I appreciate the testing and the report, very helpful!


Regards Konstantin

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Join to automatically receive all group messages.