Persist changes between scripts when BuildSourcesEphemeral=true

[kerneis-anssi]

mkosi commit the issue has been seen with

main

Used host distribution

Fedora 39

Used target distribution

Fedora 40

Linux kernel version used

6.8.5-201.fc39.x86_64

CPU architectures issue was seen on

None

Unexpected behaviour you saw

The documentation for BuildSourcesEphemeral says:

If enabled, all source directories will be reset to their original state after scripts (except sync scripts) finish executing.

I understood this to mean the following sequence of actions:

• sync scripts are executed on the source directory
• an overlay is mounted
• everything other script runs
• the overlay is discarded

In practice, it looks like a different overlay is mounted before each script runs (then discarded). Or is it before each set of script runs (ie. is there a separate overlay for every prepare script, then every build script, etc. or one for all prepare scripts, one for all build scripts, etc.)?

I think the most useful behaviour is the one I was expecting, because when the prepare script runs against the build image, I expect the result to be available to the build stage. But in any case, even if you disagree and have a use case for the current behaviour, I think the documentation should be clarified.

Used mkosi config

No response

mkosi output

No response

[DaanDeMeyer]

@kerneis-anssi Can you explain more about your use case? This would be rather complicated to change.

[kerneis-anssi]

My workflow involved pulling build dependencies locally during prepare so that I can avoid network access during build. For instance, in Go I'd use go mod vendor and in Rust cargo vendor.

I have alternative ways to reach the same goal:

• move this step to the sync phase
• move those downloads out of build sources (not all build systems handle this gracefully, but cargo allows out-of-tree vendored dependencies, and go mod download to populate the cache is an alternative to vendoring).

I'm not strongly advocating for you to implement this feature, especially if it's too complex. I think it would be useful to clarify the documentation though.

[DaanDeMeyer]

@kerneis-anssi Can't you just download these to $BUILDDIR? If it's not configurable then you can bind mount $BUILDDIR to the directory that these commands try to write to. See BuildDirectory= option.

[DaanDeMeyer]

If the paths to use can be configured via environment variables I would actually be OK with setting those automatically in mkosi.

[kerneis-anssi]

Cargo (Rust) allows working from BUILDDIR.

Go is really annoying because it will let you download the vendored dependencies anywhere, but then you need to put them under vendor/ at the root of the package you're trying to build for them to be used. I'll try playing with a bind mount of builddir, thanks for the hint!

If the paths to use can be configured via environment variables I would actually be OK with setting those automatically in mkosi.

I don't think that would solve my current issue, but I am indeed setting GOPATH, GOCACHE and others to somewhere inside BuildDirectory. I'll think about whether it makes sense to upstream those and let you know in a separate issue.

Leaving this open as a reminder to update the doc if you agree (I'll let you close as you see fit).