All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qi.Chen@windriver.com
To: openembedded-core@lists.openembedded.org
Cc: randy.macleod@windriver.com
Subject: [RFC PATCH 0/3] Add a mechanism to check runtime and recipe version mismatch
Date: Thu, 27 Mar 2025 14:21:41 +0800	[thread overview]
Message-ID: <cover.1743052694.git.Qi.Chen@windriver.com> (raw)

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

-- 
2.34.1



             reply	other threads:[~2025-03-27  6:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-27  6:21 Qi.Chen [this message]
2025-03-27  6:21 ` [RFC PATCH 1/3] version-check.conf: add mechanism for checking version mismatch Qi.Chen
2025-03-27 11:22   ` [OE-core] " Alexander Kanavin
2025-03-27 11:25     ` Richard Purdie
2025-03-28  2:42       ` ChenQi
2025-03-28 15:21         ` Quentin Schulz
2025-03-27  6:21 ` [RFC PATCH 2/3] mc: fix buildpath QA regarding unzip Qi.Chen
2025-03-27  6:21 ` [RFC PATCH 3/3] time: fix runtime version from UNKNOWN to 1.9 Qi.Chen
2025-03-27 10:56   ` [OE-core] " Ross Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1743052694.git.Qi.Chen@windriver.com \
    --to=qi.chen@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=randy.macleod@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.