On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke < [email protected]> 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: > > > > > https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630 > > 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. > > Great work, thank you! > I appreciate the testing and the report, very helpful! Bruce > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58355): https://lists.yoctoproject.org/g/yocto/message/58355 Mute This Topic: https://lists.yoctoproject.org/mt/94264665/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
