mkosi sandbox should support --runtime-{build-sources,trees,scratch}

[septatrix]

mkosi commit the issue has been seen with

main

Used host distribution

Fedora 40

Used target distribution

Fedora 40

Linux kernel version used

6.11.6-200.fc40.x86_64

CPU architectures issue was seen on

x86_64

Unexpected behaviour you saw

mkosi sandbox is supposed to provide the same environment as mkosi {qemu,boot,shell} but the runtime mounts do not seem to get applied.

This would be great for more capable mkosi.clangd files (and similar wrapper files). Currently they are implemented as special cases of build scripts though this comes with the disadvantage that other build scripts are still run which can have unexpected side effects. I also think there is no easy way to influence the order of build scripts (by e.g. prefixing files with numbers).

Another disadvantage of the wrapper scripts is that they call mkosi and expect that it is in the path. This might not always be the case as people can invoke it directly though bin/mkosi (here) or .venv/bin/mkosi (unactivated python venv). Furthermore, wrapper scripts make it hard to specify args to mkosi like -C while still allowing for args to the wrapped command clangd --limit-references=0.

With mkosi sandbox this could often be simplified (and a method to obtain the config from inside the sandbox would be nice like $MKOSI_CONFIG in build scripts)

Used mkosi config

No response

mkosi output

No response

[septatrix]

After some discussion my intended use-case for this would still be infeasible after the change though it might still be useful for other scenarios (and for consistency's sake). For my use-case #3208 is better suited

[DaanDeMeyer]

I don't think this is useful, --runtime-trees is not implementable as you'd very quickly run into privilege issues since the mount destination for those is user decided. --runtime-build-sources could be useful but all the source directories will be accessible without it as well. --runtime-scratch is pointless since /var/tmp from the host is just accessible.

I doubt running clangd from the sandbox is the way to go, it can only run out of the box when running within the same build environment. Running it from the sandbox would require modifications to make it use the proper includes from the target instead of the host.

So I'm not convinced of the use case for this so let's close this.