CLOS-6809: compare Governor DB versions numerically, not by spelling

[prilr]

A Governor-managed MariaDB 11.4 system could not be upgraded at all: leapp inhibited with "cl-mysql.repo does not match the installed database type", naming an expected repository path of cl-mariadb-11.4 that does not exist.

The original issue describes this as a deadlock between two checks. That's not quite correct.
Governor derives the token it caches in mysql.type.installed with exactly the expression leapp uses in get_clmysql_version_from_pkg():

"%s%s" % (name, "".join(version.split(".")[:2]))     # 11.4.12 -> mariadb114

Both sides therefore agree on an untouched system and the "Mismatch between Governor DB type and installed packages" inhibitor cannot fire.
It appears only after a customer follows a remediation hint and hand-writes mariadb1104 into the file. The single real bug is that leapp then predicted the repository directory from that token. Governor's spelling is a hand-maintained table rather than an algorithm: the 11.x series pads the minor version to two digits (cl-mariadb-11.04) while 10.x does not (cl-mariadb-10.6), so the prediction produced a phantom cl-mariadb-11.4.

Verified against repo.cloudlinux.com on 2026-08-05 - cl-mariadb-11.04 and cl-mariadb-11.08 return 200 for both cl8 and cl9, cl-mariadb-11.4 and cl-mariadb-11.8 return 404 - so no edit of cl-mysql.repo can satisfy the check either, and the remediation hint leapp printed pointed at a 404.

Solution: rather than mirror Governor's spelling table in leapp, parse both sides to a numeric (family, major, minor) triple and compare that. The two spellings collapse onto it - mariadb114 and mariadb1104 are both ("mariadb", 11, 4) - so the check needs no knowledge of how Governor spelled anything, and the same applies to the repository URL. A mirrored table was implemented first and rejected on review: it is correct only until Governor adds a series with a single-digit minor under a two-digit major (a future 12.4 would be cl-mariadb-12.04), and then it fails the same way, silently.

The second change closes the last place that still needed the spelling. The DNF module stream name is built from the token (mariadb1104 -> cl-MariaDB1104), and for a series absent from MODULE_STREAMS the code derived it from the cached token, whose padding Governor has dropped - so a future MariaDB 12.4 would have enabled cl-MariaDB124 where the real stream is cl-MariaDB1204. That failure is quieter than the original one: a MEDIUM report rather than an inhibitor, so the upgrade proceeds and only fails later when DNF cannot enable a module that does not exist.

The cl-mysql-meta repository directory carries the same digits as the stream, padding included, so the stream is now read from there - checked against all 17 (repo directory, module stream) pairs in governor-mysql 1.2-147, every one reproduces exactly. MODULE_STREAMS still takes precedence, because it records streams verified to exist; the repository is consulted only for a series it does not cover. Reading it is safe at that point because the handler has already inhibited the upgrade if the repository disagrees with the installed database.

Net effect: a newly released Governor DB version needs no leapp change at all.

No mariadb1108 entry is added to MODULE_STREAMS on purpose. Governor declares mariadb:cl-MariaDB1108, but the published cl-mariadb-11.08 repository carries no modules.yaml on either cl8 or cl9, and dnf module list against it returns no module - unlike cl-mariadb-11.04, which does contribute the cl-MariaDB1104 stream. Leaving it out keeps the "module stream was derived automatically" report, which is a signal we want to keep.

MariaDB 11.8 now resolves to the correctly spelled cl-MariaDB1108 via the repository rather than a phantom cl-MariaDB118.

The URL remediation no longer names a repository file to download. Predicting that filename is what produced the 404 here, and re-running mysqlgovernor.py --install --yes regenerates cl-mysql.repo correctly by definition (and if it doesn't, that's a separate topic).

The report now states both versions - the installed one and the one the repository describes - instead of a path the customer cannot fetch.

Validated with the reporter's package set (governor-mysql-1.2-147, cl-MariaDB1104-11.4.12, leapp-upgrade-el8toel9-0.20.0-9): reproduced on stock packages with no manual edits, hitting the same report key and the same 404 hint.

After the change leapp preupgrade reaches the end with no inhibitors, produces target repo cl-mysql-meta-9 -> .../cl9/mysqlmeta/cl-mariadb-11.04/$basearch/, enables mariadb:cl-MariaDB1104, and the CL9 dnf transaction check resolves. Note that leapp skips TargetTransactionCheck entirely while any inhibitor remains, so clearing the DB-type inhibitor alone would not have proven the transaction.