Hi Slava,
On 23.10.2023 19:05, Vyacheslav Yurkov wrote:
On 23.10.2023 14:18, Lukas Funke wrote:
Hi Slava,
On 22.10.2023 20:34, Vyacheslav Yurkov wrote:
Hey Lukas,
Thanks a lot for the patch. A few questions/comments from my initial
test below.
- I tried it with a go-based backend I have by providing ssh URL to
github. It seems like the GO_IMPORT is set to a module name from
go.mod of my project, which of course fails to fetch it like that,
because it's not a valid URL. How is it supposed to be used?
Your assumption is correct: the GO_IMPORT is taken from the go.mod file.
I've not considered the case where the repo URL is unequal to the
module path. This may require manual rework of the recipe. Another
solution would be to take the source URL from the recipetool. I think
there is no correct solution to this problem, because probably most
people might want to have the original solution, since they are
creating recipes from oss components (i.e. from github).
Ah, it could be that module name is not used correctly in our backend.
I'll try to put a proper URL there, thanks.
The file will explode anyway. Thanks 'go'.
Adding more intelligence to the underlying license detection could be
an idea: in your first example, the license file contains actually two
licenses: MIT and Apache. Yocto has no way to detect those cases.
Yeah, I only mentioned 2 out of 20 in my email to not make it huge ;)
There are indeed around 20. I'll try to prepare the list and send the
patch to include them.
- Could please clarify where does the version from go.mod hide? Is it
taken directly from go.mod? I'm trying to understand what should be
the workflow when a module version should be bumped up in the go.mod.
Will that be reflected in the recipe in any way?
No, currently the go-version doesn't play a role ATM. Except one case
when you have a go.mod file with go < 1.17. These go.mod files don't
include indirect dependencies.
Still trying to wrap my head around... When there's no version at
parsing stage, how this will affect reproducibility? If it's not known,
then whenever the version is bumped up in go.mod, a manual 'clean all'
will be required? (It's probably the same as now though).
Maybe I don't understand the problem: Is it required for the go module
to have the *same* version as the golang package in yocto? In my
understanding, when the golang version is greater-equal to the go.mod
version we're good?
Thanks,
Slava
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189636):
https://lists.openembedded.org/g/openembedded-core/message/189636
Mute This Topic: https://lists.openembedded.org/mt/102017388/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
