Re: Dealing with go dependencies in recipes - native docker-compose
|
Bruce Ashfield
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: 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: Completely random. I just put it there. I'll make that adjustment in the recipe.
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.
I appreciate the testing and the report, very helpful! Bruce
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II |
|
|