linux, linux-esx: share the canister/.config logic via canister_config.inc

[dcasota]

linux.spec and linux-esx.spec implemented the same canister Kconfig handling in two different idioms, and they disagreed on exactly one constellation.

Which constellation breaks, and why only that one

The generic aarch64 kernel — linux, fips=0. 16 of the 56 linux cells.

linux-esx.spec used %if 0%{?fips} / %else, and its %else branch cleaned the GCC_PLUGIN_{MATCH,PAD}_CANISTER_STRUCTS comments out of .config under the comment "Clean up .config of FIPS related configs". linux.spec instead used two independent %if 0%{?canister_build} / %if 0%{?canister_usage} blocks with no %else — so when fips=0 neither fired, the shipped .config kept the is not set comments, make olddefconfig dropped them, and the check_for_config_applicability.inc diff guard failed %prep.

Why no other cell is affected:

constellation	behaviour
x86_64, any flags	fips is %global-set to 1 inside %ifarch and cannot be overridden with -D, so fips=0 is unreachable
acvp_build=1 or kat_build=1	both force fips=1, so even on aarch64 they land in the canister branches
fips=1 + canister_build=1	only the canister_build block fires — identical seds, identical order
fips=1 + canister_usage=1 (production x86_64, both flavours)	only the canister_usage block fires; that sed text was already character-identical in the two specs
esx + -D canister_build 1	still pinned to 0 inside the %if fips block, so the branch stays unreachable for esx

The change

Three conditional blocks move into SPECS/linux/canister_config.inc, pulled in by both specs as Source5 + %include — the same mechanism both already use for check_for_config_applicability.inc. Divergence between the flavours is now impossible by construction rather than caught later. Rationale lives in %dnl lines so it doesn't leak into the expanded %prep.

linux-esx.spec additionally gains the derived-flag block linux.spec already had (canister_build=0, canister_usage=fips), nested inside the existing %if fips so it doesn't shadow -D. esx never builds a canister — it untars a prebuilt one — so fips=1 ⇒ canister_usage=1, reproducing the old branch exactly.

Testing — 112 cells

2 specs × {x86_64, aarch64} × subrelease {91, 92} × 14 flag combinations of fips / canister_build / canister_usage / acvp_build / kat_build. aarch64 reached with rpmspec --target aarch64; no spec was edited to simulate it.

	result
linux-esx, all 28 x86_64 cells	%prep byte-identical (only the release string moves)
linux-esx, all 28 aarch64 cells	same executable lines, canister seds reordered after the jitterentropy seds
linux, all 28 x86_64 cells	executable lines identical; only the 6 PR#14 shell-comment lines removed
linux, 12 aarch64 cells where acvp/kat force fips=1	executable lines identical
linux, 16 aarch64 fips=0 cells	PR#14's broad sed → linux-esx's narrow pair

Whole-spec diff (not just %prep) across all 112 cells shows nothing moved in %build, %install, %files or package metadata.

The two deltas are proven no-ops, not argued

Broad sed vs narrow pair, executed against every shipped config:

config_aarch64        IDENTICAL   (canister lines in original: 0)
config-esx_aarch64    IDENTICAL   (0)
config_x86_64         IDENTICAL   (2)
config-esx_x86_64     IDENTICAL   (2)
config_x86_64_acvp    IDENTICAL   (0)

Root cause: no config contains a CANISTER_STRUCTS=y form — only the # … is not set comment form. So the narrow pair matches everything the broad form would. Neither aarch64 config mentions the symbols at all, which is why the one cell that changed is also the one where both forms do nothing.

Reordering on esx aarch64: the canister seds and the jitterentropy seds touch disjoint symbols (CONFIG_GCC_PLUGIN_*_CANISTER_STRUCTS vs CONFIG_CRYPTO_JITTERENTROPY_*) and sed -i is line-local, so order cannot matter. The include is placed after the %if fips block deliberately, so the fips=1 ordering (tar -xvf fips-canister… → touch → canister sed) is untouched.

support/spec-checker/check_spec.py exits 0 on both specs.

Supersedes the standalone fix in #14 — same behaviour, now in the shared include.