go-mod.bbclass and gomod:// do not have all sources codes available after do_unpack

go-mod.bbclass and gomod:// do not have all sources codes available after do_unpack

[ChenQi]

Hi All,

When I was checking recent nerdctl issue about rm_work failure, I found 
that our gomod handling has some problem.

In short, source codes are not available after do_unpack. They are only 
put in place during do_compile.

I think that's why go-mod.bbclass has:
"""
addtask do_compile before do_populate_lic
"""

But this is quite a workaround. do_populate_lic is not the only one that 
need to have full source codes.

For example, meta/classes/archiver.bbclass needs sources codes. There 
must be other classes that assume sources are there after do_unpack and 
modified sources are there after do_patch.

Another big problem is patching. When source codes are only there at 
do_compile, this means we cannot patch it. But Yocto should have full 
control of the sources, we need to be able to patch any file we want.

In summary, from what I see, the current gomod mechanism does not meet 
Yocto's requirement of fully controlling the sources.

I'm bringing this problem up to have more discussion.

Regards,
Qi

Re: [OE-core] go-mod.bbclass and gomod:// do not have all sources codes available after do_unpack

[Christian Lindeberg]

On Mon, Feb  2, 2026 at 10:36 AM, Chen Qi wrote:

 > Hi All,
 >
 > When I was checking recent nerdctl issue about rm_work failure, I found
 > that our gomod handling has some problem.
 >
 > In short, source codes are not available after do_unpack. They are only
 > put in place during do_compile.
 >
 > I think that's why go-mod.bbclass has:
 > """
 > addtask do_compile before do_populate_lic
 > """

Yes, there was a suggestion in the early reviewing to keep it simple and
delegate the unpacking of the dependencies to the go tool instead of
duplicating the logic.

 >
 > But this is quite a workaround. do_populate_lic is not the only one that
 > need to have full source codes.
 >
 > For example, meta/classes/archiver.bbclass needs sources codes. There
 > must be other classes that assume sources are there after do_unpack and
 > modified sources are there after do_patch.
 >
 > Another big problem is patching. When source codes are only there at
 > do_compile, this means we cannot patch it. But Yocto should have full
 > control of the sources, we need to be able to patch any file we want.

I think the approach taken by Khem in for example the influxdb recipe by
patching the go.mod file with a module replace to a fork fits most cases as
you need the fork to do the PR anyway.

Then there is the alternative of doing the module replace with a local
directory if you want to keep the module cache untainted.

 >
 > In summary, from what I see, the current gomod mechanism does not meet
 > Yocto's requirement of fully controlling the sources.
 >
 > I'm bringing this problem up to have more discussion.

I see two main alternatives. Either to continue letting the go tool 
unpack the
dependencies but triggered earlier in unpack task instead of compile 
task. Or
let the gomod and gomodgit fetchers unpack fully.

 >
 > Regards,
 > Qi
 >
 >

Regards,
Christian