`photon-subrelease` gating - clarifications and CPE integration

[dcasota]

Is your feature request related to a problem? Please describe.

The adoption of photon-subrelease as a kernel-generation gate in Photon OS 5.x builds is a welcome improvement. Congratulations to the team. A few issues and questions have surfaced during testing.

Branch 6.0 (photon-subrelease=100)

Setting photon-subrelease=100 in 6.0/build-config.json causes build failures: snapshot 100 does not exist on Broadcom Artifactory (only 90, 91, 92 are published). Since the 6.0 branch is a development branch for the 6.12.x kernel rather than a standalone release, a working configuration is:

• photon-subrelease = "92" - activates the 6.12.x kernel specs via build_if >= 92

• photon-mainline = "92" - matches subrelease so the snapshot lookup is skipped; linux-fips-canister resolves from the base repo instead

Branch 5.0 (photon-subrelease=92)

With photon-subrelease=92, the 5.0 branch skips its own 6.1.x kernel specs (build_if <= 91 evaluates false) and activates the common 6.12.x specs instead. This might be the intended behavior? A working configuration is:

• photon-subrelease = "91" - activates the branch-specific 6.1.x kernel specs

• photon-mainline = "92" (unchanged) - since 91 != 92, snapshot 91 is used (verified available)

Branch 4.0

Self-contained build system with no photon-subrelease concept. No changes needed.

Questions

1. Is the numbering scheme intentional - i.e., are subrelease values <= 91 reserved for the 6.1.x kernel stream and >= 92 for 6.12.x, with 100 intended as a future Photon OS 6.0 starting point?

2. What is the intended correlation between the following build-config.json parameters?

   Parameter                │ Observed role
   -------------------------+--------------------------------------------------------------------------------------------------
   `photon-release-version` │ OS major release (`"5.0"`); sets `%{photon_release_version}` macro and `$releasever` in repo URLs
   `photon-subrelease`      │ Sub-version gating kernel spec selection (`%{photon_subrelease}`) and snapshot URL resolution
   `photon-mainline`        │ Snapshot bypass: when equal to `photon-subrelease`, snapshot pinning is skipped
   `photon-docker-image`    │ Docker image tag for the build sandbox (e.g. `photon:5.0`)
   `ph-docker-img-url`      │ URL to the rootfs tarball used to create the Docker base image
   `ph-builder-tag`         │ Docker tag for the enhanced builder image (rootfs + build tools)

3. Is there a plan to integrate a Common Platform Enumeration (CPE) name into photon-release.spec? Currently, /usr/lib/os-release does not include a CPE_NAME field. The CPE 2.3 URI binding offers fields that can distinguish deployment context (VM, container) and kernel variant:

   cpe:/o:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

   CPE field    │ Proposed value                 │ Purpose
   -------------+--------------------------------+-------------------------------------------------------------------
   `part`       │ `o`                            │ Operating system
   `vendor`     │ `broadcom`                     │ vendor
   `product`    │ `photon_os`                    │ Product identifier
   `version`    │ `5.0`                          │ From `photon-release-version`
   `update`     │ `92`                           │ From `photon-subrelease`
   `edition`    │ -                              │ Unused (e.g. minimal, full)
   `language`   │ -                              │ Unused (default: english)
   `sw_edition` │ `esx`, `rt`, or `generic`      │ Kernel variant (maps to linux-esx, linux-rt, linux)
   `target_sw`  │ `esxi`, `oci`                  │ Deployment context -- hypervisor, container runtime
   `target_hw`  │ `x86_64` or `aarch64`          │ Processor architecture
   `other`      │ -                              │ Unused

This yields distinct CPE names per deployment scenario:

   Scenario                   │ CPE_NAME
   ---------------------------+-----------------------------------------------------------
   VM on ESXi (esx kernel)    │ `cpe:/o:broadcom:photon_os:5.0:92:::esx:esxi:x86_64:`
   Container (OCI, no kernel) │ `cpe:/o:broadcom:photon_os:5.0:92:::container:oci:x86_64:`

Describe the solution you'd like

The suggestion above would allow /etc/photon-release to expose:

VM example (ESXi, esx kernel):

    ID=photon
    NAME="VMware Photon OS"
    VERSION="5.0"
    VERSION_ID=5.0
    VERSION_CODENAME=Photon
    PRETTY_NAME="VMware Photon OS/Linux"
    VARIANT="esx"
    VARIANT_ID=esx
    CPE_NAME=cpe:/o:broadcom:photon_os:5.0:92:::esx:esxi:x86_64:

Container example (OCI):

    ID=photon
    NAME="VMware Photon OS"
    VERSION="5.0"
    VERSION_ID=5.0
    VERSION_CODENAME=Photon
    PRETTY_NAME="VMware Photon OS/Linux"
    VARIANT="container"
    VARIANT_ID=container
    CPE_NAME=cpe:/o:broadcom:photon_os:5.0:92:::container:oci:x86_64:

Detection at build time or first boot could populate these fields: the kernel variant is known from the installed linux; the deployment context can be derived from systemd-detect-virt.

Reference build environment

 Kernel:    Linux 6.12.69-4.ph5-esx (gcc 12.2.0, GNU ld 2.39)
 Platform:  VMware VMware20,1 / x86-64
 BIOS:      VMW201.00V.24866131.B64.2507211911
 FIPS:      enabled (fips=1)

Describe alternatives you've considered

No response

Additional context

The photon-gating-conflict-detection project addresses the constellation systematically when photon-subrelease, photon-mainline, and snapshot availability might fall out of sync by scanning all spec files against build_if thresholds and remote repository state, detecting six distinct conflict constellations (package splits, cross-dependencies, subrelease boundary mismatches, cross-branch contamination, FIPS canister coupling, and snapshot URL availability) before a build even starts. Integrating such a detection as a CI pre-flight check would give to the Photon OS team immediate visibility into which subrelease values are safe for which branches, directly answering the correlation and numbering-scheme questions.