Pass variables with host properties to scripts

[davide125]

mkosi commit the issue has been seen with

main

Used host distribution

Fedora Linux 41

Used target distribution

Fedora Linux 41

Linux kernel version used

No response

CPU architectures issue was seen on

None

Unexpected behaviour you saw

It would be useful to know the host distribution, release and architecture when inside scripts such as mkosi.sync; while detection is easy enough to reimplement, mkosi is already doing it and uses a consistent format (e.g. it always refers to aarch64 as arm64). For these, I'd suggest adding $HOST_DISTRIBUTION, $HOST_RELEASE, $HOST_ARCHITECTURE. It would also be useful to have a $MKOSI variable pointing to the mkosi binary, so that if one needs to run mkosi from inside one of the scripts it'll be guaranteed to be the same version.

Used mkosi config

No response

mkosi output

No response

[septatrix]

What is you use case - should this also apply to the tools tree distro?

[davide125]

In https://github.com/davide125/arcadeos/blob/66435dd4328aa16fc8d58b98e379a7ef3640d975/mkosi.sync I'm building systemd inside mkosi.sync; this is done by calling mkosi, and it would be good to ensure it's the same mkosi that's running one level up (hence the $MKOSI variable suggestion). As for the host distribution variables, in this scenario the inner mkosi build (for the "host" systemd) ends up building a tools tree, and I would like to ensure it's always targeting the host distribution and release (right now e.g. it will build debian testing when run on ubuntu, which seems to be fine in practice, but IMO is a needless deviation).

[davide125]

And to elaborate, IMO $HOST_DISTRIBUTION and friends should always be the actual host, regardless of whether a tools tree is in play; we should add a separate set for the tools tree (say, $TOOLS_TREE_DISTRIBUTION etc) if that's desired.

[septatrix]

Not quite sure why you need to build systemd for the host and the target but I assume you will have your reasons. For now a workaround could be to mount your host's os-release under a different path as a build source and source it inside your script. Mkosi, I think, will always refer to the same binary as you invoked it with (maybe unless you install a mkosi on the tools tree, not sure about that)