spk.mk: Limit os_max_ver to point release updates for kernel spk

[th0ma7]

Motivation: When providing kernel module packages we must not alow it to run on newer DSM versions. Only acceptable point releases which equal to <10 increase on build number such as:

• COMPATIBLE: Package built for DSM-6.2.3 = 6.2-25423 and point releases DSM-6.2.3 Update 3 = 6.2-25426
• INCOMPATIBLE: Package built for DSM-6.2.3 = 6.2-25423 while DSM-6.2.4 = 6.2-25556

Linked issues: #4420, #4144

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

[th0ma7]

Such code would produce the following for package using REQUIRE_KERNEL :

package="synokernel-usbserial"
version="1.0-6"
description="Includes usbserial.ko ch341.ko cp210x.ko pl2303.ko ti_usb3410_5052.ko and ftdi_sio.ko"

arch="apollolake"
maintainer="th0ma7"
maintainer_url=""
distributor=""
distributor_url=""
os_min_ver="6.2-25423"
os_max_ver="6.2-25433"
helpurl="https://www.kernel.org/"
displayname="SynoKernel USB Serial drivers"
dsmuidir="app"
dsmappname="com.synocommunity.synokernel-usbserial"
dsmapppage="com.synocommunity.synokernel-usbserial"
dsmapplaunchname="com.synocommunity.synokernel-usbserial"
changelog="1. Synology Kernel USB serial drivers"
install_dep_packages="synocli-kernel"
checksum="6a79b5f17b94fefce3e8d57a0dd65ee3"

[publicarray]

Looks good, but I'm just not sure about the magic 10 since I could never make sense of their build number scheme, I just though it increased internally on every iteration. Can we do this check on major.minor.patch version string? Forgive me if it's a bad question.

[th0ma7]

@publicarray indeed, their building scheme is not that obvious.
Further more they use 4.4.59+ for DSM-6.2 although the code is quite different from one sub-version to another as they backported patches related to Meltdown/Spectre/L1TF to 4.4.59 instead of upgrading to 4.4.108-116 (spectre/metldown) or 4.4.148 for L1TF.

As such, we can't expect kernel modules to be compatible between 6.2, 6.2.1, 6.2.2, etc. Therefore we need a safeguard so that package would get disabled in case of a kernel upgrade. The hope here is to use os_max_ver to circumvent the issue.

The one rule that works is for sub-updates. Lets use DSM-6.2.3 for instance:

1. Point release update 1-2-3 keep the same version (e.g. 6.2.3)
2. keep the same kernel (updates are aimed towards CVE package fixes or bug-fixes)
3. add the Update 1-2-3 to the version label
4. increase the build number by +1

With that in mind, setting the os_max_ver is a safe bet: it allow room DSM security updates where the kernel is unaffected.

Here a package built for DSM-6.2.3 would still work for DSM-6.2.3 Update 1-2-3, but not for DSM-6.2.4.

• DSM-6.2.3 = 6.2-25423
• DSM-6.2.3 Update 1 = 6.2-25424 (same kernel, build+1)
• DSM-6.2.3 Update 2 = 6.2-25425 (same kernel, build+2)
• DSM-6.2.3 Update 3 = 6.2-25426 (same kernel, build+3)
• DSM-6.2.4 = 6.2-25556 (new kernel, build >= +100)
• DSM-7.0beta= 7.0-40000 (new kernel, build >= +100)

I've added @ymartin59 and @hgy59 to the loop as they may have thoughts about this as well.