RPM logic prohibiting server major upgrade no longer works as expected

Courtesy of tturenko's tests

On historical reasons our RPM packaging explicitly prohibits a major upgrade. The check is a part of server-prein.sh script.

It turns out that the check no longer works on newer systems, e.g. RHEL 8 or SLES 15, while still works on older ones, e.g. RHEL 7 or SLES 12.
That is, if such upgrade is attempted, on the older systems it is rejected with

...

Upgrading directly from ... to ... may not

be safe in all cases.  A manual dump and restore using mysqldump is

recommended.  It is important to review the MariaDB manual's Upgrading

section for version-specific incompatibilities.

...

and the server package is held back; while on the newer ones no error message is issued, and the server package gets upgraded.

The logic in server-prein.sh doesn't have any branches specific to OS versions. The essential part is this:

  version=`rpm -q --queryformat='%{VERSION}' "$installed" 2>&1`

  myversion='%{mysqlversion}'

<...>

  old_family=`echo $version   | sed -n -e 's,^\([1-9][0-9]*\.[0-9][0-9]*\)\..*$,\1,p'`

  new_family=`echo $myversion | sed -n -e 's,^\([1-9][0-9]*\.[0-9][0-9]*\)\..*$,\1,p'`

<...>

  if [ "$old_family" != "$new_family" ]; then

    < the error>

In order to understand what happens I added the printout in the very beginning of the script:

echo "Pre-in: Running pre-in script server-prein.sh"

echo "Pre-in: VERSION: %{VERSION}"

echo "Pre-in: mysqlversion: %{mysqlversion}"

And ran an upgrade from 10.5 to 10.6.4 with it.

It reveals the following:

01:13:55 Pre-in: Running pre-in script server-prein.sh

01:13:55 Pre-in: VERSION: %{VERSION}

01:13:55 Pre-in: mysqlversion: 10.6.4

01:18:21 Pre-in: Running pre-in script server-prein.sh

01:18:21 Pre-in: VERSION: 10.6.4

01:18:21 Pre-in: mysqlversion: 10.6.4

So, my surmise is that the script on RHEL-8 (and SLES-15) somehow already has a value substitution for %{VERSION}, and when rpm -q --queryformat='%{VERSION}' "$installed" is run, instead of referring to the version of the old installed package, it simply prints the constant. This constant becomes a value of version, which is naturally the same as myversion, thus the old_family and new_family end up to be the same, and no error occurs.

Maybe it is a good occasion to finally get rid of the limitation based on versions.

It doesn't mean that the logic can be simply removed though, it still needs to be fixed, as there is also a similar check based on VENDOR value, which is likely to be broken also, and that is better to keep for now (we once tried to relax those rules and allow upgrade from different vendors' packages, but so many problems occurred that the work had never been completed).

I've set it to 10.6 because it's the only version which I tried, and I can't make a decent guess about others based on the prein script alone, as I don't know where the substitution comes from