Context: ADR 0035
This library has the most significant divergence from the definitions in ADR 0035 and requires substantial rework:
-
CName class and the role of platform: The library's CName class treats platform as a first-class field, exposing CName.platform and CName.features["platform"] as primary identifiers. Under this ADR, platform is simply a feature of type platform that sorts to the front of the cname — it has no special status in the cname string itself. The CName class should drop platform as a first-class accessor and instead expose it via the general feature-set breakdown if needed.
-
Commit as primary cname component: The library's primary cname format is {cname}-{arch}-{version}-{commit}. The no-commit form exists only as an explicit workaround (labelled as such in a comment at cname.py:97). As a direct consequence, release_metadata_string writes GARDENLINUX_CNAME including the commit — which means release files generated by the library contain a different value for GARDENLINUX_CNAME than what the builder writes. Under this ADR, the .cname property must return only the feature encoding, and the commit-extended form should be exposed as a distinct property (e.g. .artifact_base_name). The workaround branch can be removed once the primary format is corrected.
-
flavor property: CName.flavor currently returns the feature-encoding prefix (what this ADR calls the cname). It should be renamed to cname, and a new flavor property returning {cname}-{arch} introduced.
-
flavors/parser.py: This separate module parses flavors.yaml and generates strings of the form {target}-{feature}-{arch}, which match the flavor definition here. The module name and its output are consistent with this ADR and require no renaming. However, the relationship between this module and features/parser.py (which also deals with something it calls "flavor") should be clarified in documentation.
-
Sorting: The library's get_flavor_from_feature_set uses a reduce with simple underscore/hyphen logic. This does not reproduce the lexicographical topological sort defined here. For correctness, cname construction in the library must use the same algorithm as the builder, or — preferably — delegate to the builder's parse_features script rather than reimplementing the sort, e.g. by consuming GARDENLINUX_CNAME from /etc/os-release which is already correctly sorted and minimised by the builder.
Context: ADR 0035
This library has the most significant divergence from the definitions in ADR 0035 and requires substantial rework:
CNameclass and the role ofplatform: The library'sCNameclass treatsplatformas a first-class field, exposingCName.platformandCName.features["platform"]as primary identifiers. Under this ADR, platform is simply a feature of typeplatformthat sorts to the front of the cname — it has no special status in the cname string itself. TheCNameclass should dropplatformas a first-class accessor and instead expose it via the general feature-set breakdown if needed.Commit as primary cname component: The library's primary cname format is
{cname}-{arch}-{version}-{commit}. The no-commit form exists only as an explicit workaround (labelled as such in a comment atcname.py:97). As a direct consequence,release_metadata_stringwritesGARDENLINUX_CNAMEincluding the commit — which means release files generated by the library contain a different value forGARDENLINUX_CNAMEthan what the builder writes. Under this ADR, the.cnameproperty must return only the feature encoding, and the commit-extended form should be exposed as a distinct property (e.g..artifact_base_name). The workaround branch can be removed once the primary format is corrected.flavorproperty:CName.flavorcurrently returns the feature-encoding prefix (what this ADR calls the cname). It should be renamed tocname, and a newflavorproperty returning{cname}-{arch}introduced.flavors/parser.py: This separate module parsesflavors.yamland generates strings of the form{target}-{feature}-{arch}, which match the flavor definition here. The module name and its output are consistent with this ADR and require no renaming. However, the relationship between this module andfeatures/parser.py(which also deals with something it calls "flavor") should be clarified in documentation.Sorting: The library's
get_flavor_from_feature_setuses areducewith simple underscore/hyphen logic. This does not reproduce the lexicographical topological sort defined here. For correctness, cname construction in the library must use the same algorithm as the builder, or — preferably — delegate to the builder'sparse_featuresscript rather than reimplementing the sort, e.g. by consumingGARDENLINUX_CNAMEfrom/etc/os-releasewhich is already correctly sorted and minimised by the builder.