Skip to content

Draft: Kernel versioning scheme compatible with u-boot-menu

Marcin Wcisło requested to merge linux-ce-monotonic-ver into linux-6.1-ce

Goal

To provide kernel versioning scheme which would preserve the ordering of kernels in the extlinux.conf file generated by u-boot-update.

Disclaimer

This MR is not actually supposed to be merged as-is. It's a proof of concept and a place for experiments and discussion.

Proposition

To add a fourth number localver to the official kernel version officialver. Examples:

linux-image-6.1.56.2000-whle-ls1-sdk-g166eb04eee68
linux-image-6.1.56.2001-whle-ls1-sdk-gb0c02e4d4cd1
linux-image-6.1.56.2002-whle-ls1-sdk-g5b6255b3522f
linux-image-6.1.56.2003-whle-ls1-sdk-g82774b2e2cee
linux-image-6.1.56.2004-whle-ls1-sdk-g9acec646d92c
            ^^^^^^                                   officialver
                   ^^^^                              localver
                        ^^^^^^^^^^^^                 variant
                                      ^^^^^^^^^^^^   commithash

The localver would be based on the depth level of the commit node in the git graph - the output of the command:

git rev-list --count HEAD

This naming scheme has all the desired properties (verified):

  • Partial ordering based on versioning ordering: If in the git graph the commit a is before the commit b then, for the same variant (eg. whle-ls, whle-ls1-sdk), the kernel built from commit a is always lower on the booting menu than commit b.
  • Backward compatibility: For a fixed officialver (eg. 6.1.56, 6.5.6) all kernels from the current naming scheme are lower on the booting menu than those from the proposed one.
  • Transparency for the official versioning: Kernel a with a higher officialver than that of kernel b is always higher on the booting menu, regardless of the naming scheme used for either a or b, or their variant or localver values.

Additionaly, this naming scheme is consistent with the snapshot versioning used in other packages in Conclusive repositories, eg. fmc

1.0~241.gbpb4ad38
1.0~240.gbp062e7a
1.0~239.gbpcbe27f

Challange

For git rev-list … command to work correctly the CI system needs to have a full repository during the build. Currently it's obtained with the clone method with the depth limit set to 1000 (GIT_DEPTH). This results in git rev-list … always returning 1000 in the following yaml config:

…
- DEB_VERSION="${KERNEL_VERSION}~${CI_JOB_ID}-1"
- LOCAL_VERSION="-${KERNEL_VARIANT}"
- LOCAL_VERSION="~$(git rev-list --count HEAD)-${KERNEL_VARIANT}"
…

Not limiting the cloning depth would greatly reduce performance build.

Merge request reports