On Thu, Apr 20, 2017 at 8:19 AM, Bruce Ashfield <[email protected]> wrote:
> > > On Thu, Apr 20, 2017 at 6:58 AM, Christian Holl <[email protected]> > wrote: > >> Hi, >> >> I saw that there is a implementation of Go inside >> meta-virtualization. >> >> >> I am currently trying to build influxdb, telegraf and grafana for my >> rasberrypi. >> >> And telegraf depends on docker. Which is also written in Go. >> >> But I am using oe-meta-go for other recipes and they don't work together. >> >> So there is meta-golang, oe-meta-go and meta-virtualization with go >> implementations. >> > > This process is already done in master. I was part of the discussions on > moving > go to oe-core at ELCe in berlin, and Khem took the initiative and > collected our > go changes + oe-meta-go + meta-golang and got them merged into oe-core > for the upcoming 2.3 release. > > Those changes won't be backported, but from the 2.3 release and on, we are > moving to the oe-core go variant. > And I'll post my reply from that other thread here as well: --------------------------- As for the build infrastructure, we are standardized on the oe-core go version. As for the actual go dependency recipes, they are going to stay in their respective layers for a while. Having recipes collected in layers "by language" doesn't solve the dependency problem. We have system level use cases in meta-virtualization/meta-cloud-services that require specific versions of dependent packages, and those are the recipes that are captured in the layers. A generic, language layer of dependencies marches forward at a cadence that can continually break those dependencies. So if it really matters, we need to capture the recipe in the layer (i.e. meta-virt) where it is actually tested (and not just dropped into the bucket). There's a separate discussion on the oe architecture list on how to handle languages that fetch their own dependencies up front (go, node.js, etc), and that is where the dependency problem is going to be solved. Packaging the (potentially) thousands of dependency packages isn't the solution, managing the fetch and build process is likely the way to go .. but read the thread for the thoughts and details if there's interest. ----------------------------- Bruce > Cheers, > > Bruce > > >> >> >> So could you maybe could someone responsible join our discussion, what to >> use: >> >> https://github.com/madisongh/meta-golang/issues/12 >> >> >> Kind Regards, >> >> Christian >> >> -- >> _______________________________________________ >> meta-virtualization mailing list >> [email protected] >> https://lists.yoctoproject.org/listinfo/meta-virtualization >> > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end" > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
