On 24.10.2023 08:19, Lukas Funke wrote:
- 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?
I think I mixed up with revisions here a bit. What I meant is how the
bitbake would know if versions of dependent components in go.mod have
been updated.
The easy answer I guess is that the revision of the main recipe (that
contains go.mod) needs to be updated for that, and I hope that bitbake
would refetch new versions from go.mod, but I didn't check it yet.
The more complicated scenario, what if I use a devtool workflow? Will
the fetcher be able to reparse go.mod in this case?
Slava
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189639):
https://lists.openembedded.org/g/openembedded-core/message/189639
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]
-=-=-=-=-=-=-=-=-=-=-=-
