Re: #golang: go fetches dependencies in compile phase

Robert Berger

On 09/04/2021 16:53, Juergen Landwehr wrote:
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
Alexander (whom you cc'ed here as well) wrote a long time ago on the mailing list[1] about this stuff.

We have a couple of issues with those "modern" languages like go, which behave quite differently from good old Unix stuff. So the paradigm on which the whole Bitbake/OpenEmbedded/Yocto system was built does not quite apply for those.

Don't get me wrong, you can also do stupidities like git clone via make or cmake, but this is most likely not the way those tools should be used.

1) "Guaranteed __NOT__ reproducible builds"(C)

Go pulls in dependencies by itself, which might explain why it's in the compile phase and not it the fetch phase.

This leads to many interesting issues, like "guaranteed __NOT__ reproducible builds"(C). The problem is, that you don't have any influence on dependencies of dependencies. Someone changes somewhere a dependency on github and the party starts.

1.1) One sane solution to "please give me always the same input" is what Konrad already mentioned in combination with a local golang proxy.

2) Open Source License Compliance

If you pull in all those funny dependencies and also link things statically, like with go, Open Source License Compliance is getting very interesting.

People typically just use the license of the top level "main" entry point. In reality you would need to check all the dependency tree for licenses. You should also check if it's legally allowed to combine the licenses and in case it's allowed what are implications of GPLvx, LGPLv2, LGPLv3 without exceptions for your product.




Join to automatically receive all group messages.