feat: dynamically solve all requirements.mod files

[yeoldegrove]

What this PR does / why we need it:

feat: dynamically solve all requirements.mod files

This enables adding new variables to requirements.mod files in any feature without updating the builder.

[nkraetzschmar]

Either we need to adjust the way the requirements.mod files are evaluated to ensure that they are just key=value pairs, or we need a better way to dynamically determine the set of keys.

One idea I'd have: introduce a requirements_keys array and let the mod scripts dynamically add/remove keys there and then use that for the final output. So have something like

requirements_keys=(arch uefi secureboot tpm2)

# source the requirements.mod files here which may add keys

for key in "${requirements_keys[@]}"; do
    echo "$key=${!key}"
done

[nkraetzschmar]

This makes the assumption that all requirements.mod files are of a plain key=value format. But since they get sourced there could be more complex setups, so this scanning for possible modifiers is fragile if we keep the way the requirements.mod files as is.

[yeoldegrove]

@nkraetzschmar good catch...

Either we need to adjust the way the requirements.mod files are evaluated to ensure that they are just key=value pairs, or we need a better way to dynamically determine the set of keys.

I like this being potentially dynamic for future use cases.

One idea I'd have: introduce a requirements_keys array and let the mod scripts dynamically add/remove keys there and then use that for the final output. So have something like

I like this idea but would keep the initial array minimal and only include what is not set in features, e.g. non-bool arch:

requirements_keys=(arch)

Each feature's requirements.mod file would need to be adapted (coordinated PR) e.g.

requirements_keys+=(uefi)
uefi=true

[yeoldegrove]

@nkraetzschmar Please re-review.

[yeoldegrove]

gardenlinux/gardenlinux#4912 is a companion PR that extends the requirements_keys array in the features.

[nkraetzschmar]

LGTM 🚀