On Tue, Oct 18, 2022 at 9:17 AM Bruce Ashfield via lists.yoctoproject.org <[email protected]> wrote:
> > > 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. > emux86-64-c9 login: root root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version Docker Compose version v2.11.2 Cheers, Bruce > >> >> 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 > > > > > -- - 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 (#58358): https://lists.yoctoproject.org/g/yocto/message/58358 Mute This Topic: https://lists.yoctoproject.org/mt/94264665/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
