mbox

[RFC,0/3] Add a mechanism to check runtime and recipe version mismatch

Message ID cover.1743052694.git.Qi.Chen@windriver.com
State Not Applicable, archived
Headers show

Pull-request

https://github.com/ChenQi1989/poky version-check

Message

ChenQi March 27, 2025, 6:21 a.m. UTC 
From: Chen Qi <Qi.Chen@windriver.com>

This RFC add a mechanims to check runtime and recipe version mismatch.
For example, if some tool says its runtime version is 1.0, but its recipe version is 1.1,
we can now detect it at build time.

Let me explain the most important thing in this cover letter: why.

Briefly speaking, there are two major benefits:
1) Make things look better.
2) Detect potential problems.

See more detailed explanations below.

When people use some software they care about, they would type "--version" or something similar
to check its version. And if the output does not match the package version that is installed, or
there's some "bad" words in output such as "unknown", "dirty", "dev", they would raise questions in
their minds: Does the vendor really know what it's building? Am I using stable versions? If they can't
even get versions right, how can I trust them on other things?

So here comes the first reason on adding such a mechanim: we can detect version mismatch, we can then
fix them. This makes things look better. Patch 3/3 is an example fix.

Another reason, which might be a more important reason, is that it helps us defect potential problems.
First of all, version information sometimes matters more than just showing user some info. It affects
runtime behavior. A typical example is k8s. If k8s is built with correct version info, it will try to
pull major.minor version compatible images and do its work. But if it's built with a wrong version,
either init fails or it pulls some incompatible images. Secondly, a version mismatch indicates some
potential error. Use sassc an an example. It got a version mismatch because it's not using the header
file generated under build directory. Instead, it uses the default one with the same name in source
directory. Luckily, that header file only contains version info. But this case demonstrates that
a version mismatch actually indicates some error.

During development, I found the errors that version mismatch indicates fall into the following categories:
1) The upstream project made a mistake.
   e.g.,
   libuser got a mismatch because upstream project forgets to update configure.ac/configure files.
2) The recipe made a mistake.
   e.g.,
   python3-pyyaml-include_2.2.bb got a mismatch because it's srcrev actually points to v2.2a1 tag instead
   of the v2.2 tag.
3) Some corner case will raise a mismatch that normal build does not see.
   e.g.,
   If we build libsass from git shallow tarball, we got a mismatch. The "Version" field in .pc file is
   7073 which is wrong. In a normal build, the "Version" field in the .pc file is 3.6.6 which is correct.

With this mechanism added, we can detect such problems and fix them in time.

Hope to hear your opinions.

Regards,
Qi


--- Result for oe-core world build (11 mismatches) ---
WARNING: python3-unittest-automake-output-0.2-r0 do_package_check_version_mismatch: Possible runtime versions ['0.1'] do not match recipe version 0.2
WARNING: time-1.9-r0 do_package_check_version_mismatch: Possible runtime versions ['UNKNOWN'] do not match recipe version 1.9
WARNING: pinentry-1.3.1-r0 do_package_check_version_mismatch: Possible runtime versions ['1.3.1-unknown'] do not match recipe version 1.3.1
WARNING: gnupg-2.5.5-r0 do_package_check_version_mismatch: Possible runtime versions ['1.11.0-unknown', '1.6.7-unknown', '2.5.5-unknown'] do not match recipe version 2.5.5
WARNING: dpkg-1.22.11-r0 do_package_check_version_mismatch: Possible runtime versions ['1.22.11-dirty'] do not match recipe version 1.22.11
WARNING: libgpg-error-1.51-r0 do_package_check_version_mismatch: Possible runtime versions ['1.51-unknown'] do not match recipe version 1.51
WARNING: sassc-3.6.2-r0 do_package_check_version_mismatch: Possible runtime versions ['1.1.1', '3.5'] do not match recipe version 3.6.2
WARNING: libassuan-3.0.2-r0 do_package_check_version_mismatch: Possible runtime versions ['3.0.2-unknown'] do not match recipe version 3.0.2
WARNING: libksba-1.6.7-r0 do_package_check_version_mismatch: Possible runtime versions ['1.6.7-unknown'] do not match recipe version 1.6.7
WARNING: libgcrypt-1.11.0-r0 do_package_check_version_mismatch: Possible runtime versions ['1.11.0-unknown'] do not match recipe version 1.11.0
WARNING: glslang-1_1.3.296.0-r0 do_package_check_version_mismatch: Possible runtime versions ['0.97', '15.0.0', '3.20', '4.60'] do not match recipe version 1.3.296.0
----------------------------------------


The following changes since commit 6610cad12a062592956257961a790ec6a3012b8b:

  bitbake: data_smart: Ensure module dependency changes invalidate the base config cache (2025-03-13 21:21:04 +0000)

are available in the Git repository at:

  https://github.com/ChenQi1989/poky version-check
  https://github.com/ChenQi1989/poky/tree/version-check

Chen Qi (3):
  version-check.conf: add mechanism for checking version mismatch
  mc: fix buildpath QA regarding unzip
  time: fix runtime version from UNKNOWN to 1.9

 meta/classes/check-version-mismatch.bbclass   | 399 ++++++++++++++++++
 meta/{classes-recipe => classes}/qemu.bbclass |   0
 meta/conf/version-check.conf                  |  14 +
 meta/recipes-extended/mc/mc_4.8.33.bb         |   1 +
 meta/recipes-extended/time/time_1.9.bb        |   6 +
 5 files changed, 420 insertions(+)
 create mode 100644 meta/classes/check-version-mismatch.bbclass
 rename meta/{classes-recipe => classes}/qemu.bbclass (100%)
 create mode 100644 meta/conf/version-check.conf