[meta-virtualization] Can we have a standard approach for Go?

[Bruce Ashfield]

On Thu, Apr 20, 2017 at 8:19 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
wrote:

>
>
> On Thu, Apr 20, 2017 at 6:58 AM, Christian Holl <cyborgx1 at gmail.com>
> 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
>> meta-virtualization at yoctoproject.org
>> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20170420/8ab8e7fc/attachment-0001.html>