Re: [PATCH] linux-custom: support to add linux-libc-dev package with kernel name

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 11.09.25 07:21, Arulpandiyan Vadivel wrote:
> 
> 
> On Thursday, 11 September 2025 at 10:41:19 UTC+5:30 Jan Kiszka wrote:
> 
>     On 10.09.25 19:22, 'Jan Kiszka' via isar-users wrote:
>     > On 10.09.25 15:55, 'Jan Kiszka' via isar-users wrote:
>     >> On 21.01.25 10:47, 'Arulpandiyan Vadivel' via isar-users wrote:
>     >>> Debian and Ubuntu use unified kernel headers and a single linux-
>     libc-dev
>     >>> package is shipped. In contrast, Isar may build multiple kernel
>     variants
>     >>> with different versions and/or patches and their packages but
>     linux-libc-dev
>     >>> are suffixed with -${KERNEL_NAME_PROVIDED}: this allows
>     >>> each variant to exist in isar-apt (reprepro may not have more
>     than one
>     >>> version of a given package for a given suite).
>     >>> Apply the same suffix to linux-libc-dev / linux-libc-dev-
>     ${DISTRO_ARCH}-cross
>     >>> and a Provides: clause.
>     >>>
>     >>> Signed-off-by: Arulpandiyan Vadivel <arulpandiy...@siemens.com>
>     >>>
>     >>> ---
>     >>> Changes since v4
>     >>> - Updated KERNEL_PKG_LIBC_HEADERS path with KERNEL_NAME_PROVIDED
>     >>>
>     >>> Changes since v3
>     >>> - Updated commit message to include cross packages
>     >>> - updated doc/custom_kernel.md documentation
>     >>>
>     >>> Changes since v2
>     >>> - Updated commit message as suggested
>     >>> - Added KERNEL_NAME_PROVIDED for cross packages of linux-libc-
>     dev as well
>     >>>
>     >>> ---
>     >>> ---
>     >>> RECIPE-API-CHANGELOG.md | 12 ++++++++++++
>     >>> doc/custom_kernel.md | 4 ++--
>     >>> meta/recipes-kernel/linux/files/debian/control.tmpl | 10 +++++++---
>     >>> .../linux/files/debian/isar/common.tmpl | 2 +-
>     >>> .../linux/files/debian/isar/install.tmpl | 2 +-
>     >>> meta/recipes-kernel/linux/linux-custom.inc | 2 ++
>     >>> 6 files changed, 25 insertions(+), 7 deletions(-)
>     >>>
>     >>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
>     >>> index f310553a..64c0f34a 100644
>     >>> --- a/RECIPE-API-CHANGELOG.md
>     >>> +++ b/RECIPE-API-CHANGELOG.md
>     >>> @@ -702,3 +702,15 @@ enable cross-compilation. Otherwize
>     ISAR_CROSS_COMPILE = "0" now should be set
>     >>> in local.conf to disable cross-compilation for all the recipes.
>     >>> Sample local.conf from meta-isar used by isar-init-build-env is
>     also changed
>     >>> to enable cross-compilation by default.
>     >>> +
>     >>> +### Enable linux-libc-dev package with KERNEL_NAME
>     >>> +
>     >>> +By default linux-libc-dev and linux-libc-dev-${DISTRO_ARCH}-
>     cross package
>     >>> +was generated for architecture it builds for.
>     >>> +
>     >>> +This change helps to generate the `linux-libc-dev-
>     ${KERNEL_NAME}` and
>     >>> +`linux-libc-dev-${DISTRO_ARCH}-cross-${KERNEL_NAME}`.
>     >>> +For example, If `KERNEL_NAME` is configured as `foo` for arm64,
>     now
>     >>> +`linux-libc-dev-foo` and `linux-libc-dev-arm64-cross-foo`
>     package will be
>     >>> +generated. This will help to have multiple versions of linux-
>     libc-dev packages
>     >>> +available for respective bsps in apt feeds.
>     >>> diff --git a/doc/custom_kernel.md b/doc/custom_kernel.md
>     >>> index ce5f1bf7..2dca577c 100644
>     >>> --- a/doc/custom_kernel.md
>     >>> +++ b/doc/custom_kernel.md
>     >>> @@ -51,9 +51,9 @@ The linux-custom recipe provides support for:
>     >>>
>     >>> Only the `host` specific package is built automatically at cross
>     builds.
>     >>>
>     >>> - 10. Produce a `linux-libc-dev` package to support user-land
>     builds
>     >>> + 10. Produce a `linux-libc-dev-${KERNEL_NAME}` package to
>     support user-land builds
>     >>>
>     >>> - 11. Only build/ship the `linux-libc-dev` package if instructed to
>     >>> + 11. Only build/ship the `linux-libc-dev-${KERNEL_NAME}`
>     package if instructed to
>     >>> (`KERNEL_LIBC_DEV_DEPLOY` equals to `"1"`)
>     >>>
>     >>> 12. Support both native and cross compiles (`ISAR_CROSS_COMPILE`)
>     >>> diff --git a/meta/recipes-kernel/linux/files/debian/control.tmpl
>     b/meta/recipes-kernel/linux/files/debian/control.tmpl
>     >>> index ec0da1ab..a79b86c4 100644
>     >>> --- a/meta/recipes-kernel/linux/files/debian/control.tmpl
>     >>> +++ b/meta/recipes-kernel/linux/files/debian/control.tmpl
>     >>> @@ -22,19 +22,23 @@ Description: ${KERNEL_NAME_PROVIDED} Linux
>     kernel headers for @KR@
>     >>> .
>     >>> This is useful for people who need to build external modules
>     >>>
>     >>> -Package: linux-libc-dev
>     >>> +Package: linux-libc-dev-${KERNEL_NAME_PROVIDED}
>     >>> Build-Profiles: <!nolibcdev kernel>
>     >>> Section: devel
>     >>> -Provides: linux-kernel-headers
>     >>> +Conflicts: linux-libc-dev
>     >>> +Provides: linux-libc-dev
>     >>> +Replaces: linux-libc-dev
>     >>> Architecture: ${KERNEL_LIBC_DEV_ARCH}
>     >>> Description: Linux support headers for userspace development
>     >>> This package provides userspaces headers from the Linux kernel.
>     These headers
>     >>> are used by the installed headers for GNU glibc and other system
>     libraries.
>     >>>
>     >>> -Package: linux-libc-dev-${DISTRO_ARCH}-cross
>     >>> +Package: linux-libc-dev-${DISTRO_ARCH}-cross-
>     ${KERNEL_NAME_PROVIDED}
>     >>> Build-Profiles: <!nolibcdev cross !kbuild>
>     >>> Section: devel
>     >>> +Conflicts: linux-kernel-headers-${DISTRO_ARCH}-cross
>     >>> Provides: linux-kernel-headers-${DISTRO_ARCH}-cross
>     >>> +Replaces: linux-kernel-headers-${DISTRO_ARCH}-cross
>     >
>     > This was also wrong.
>     >
>     >>> Architecture: all
>     >>> Description: Linux Kernel Headers for development (for cross-
>     compiling)
>     >>> This package provides headers from the Linux kernel. These headers
>     >>> diff --git a/meta/recipes-kernel/linux/files/debian/isar/
>     common.tmpl b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
>     >>> index f9cc2f02..b004214f 100644
>     >>> --- a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
>     >>> +++ b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl
>     >>> @@ -8,7 +8,7 @@ set -e
>     >>> ARCH=${KERNEL_ARCH}
>     >>> KERNEL_PKG_IMAGE=linux-image-${KERNEL_NAME_PROVIDED}
>     >>> KERNEL_PKG_KERN_HEADERS=linux-headers-${KERNEL_NAME_PROVIDED}
>     >>> -KERNEL_PKG_LIBC_HEADERS=linux-libc-dev
>     >>> +KERNEL_PKG_LIBC_HEADERS=linux-libc-dev-${KERNEL_NAME_PROVIDED}
>     >>> KERNEL_PKG_LIBC_HEADERS_CROSS=linux-libc-dev-${DISTRO_ARCH}-cross
>     >>
>     >> This broke the cross libc-dev package. Fix is being tested.
>     >>
>     >> Seems we are lacking tests for this scenario: found via xenomai-
>     images
>     >> only, and there we were lacking CI for the affected path as well :(.
>     >>
>     >
>     > There is another issue with this patch which was likely hard to
>     predict:
>     > It broke automatic downgrades, possibly also updates, of libc-dev
>     in the
>     > sbuild-chroots. As xenomai-images is currently broken in other
>     regards
>     > as well, I cannot easily point to a demo case, but I reproduced that
>     > locally: After reverting this change, I can build libevl, which
>     really
>     > needs the custom kernel's libc-dev because of extra headers,
>     without any
>     > extra dependency.
>     >
>     > [...]
>     > Reading package lists...
>     > Building dependency tree...
>     > Reading state information...
>     > Calculating upgrade...
>     > The following packages will be upgraded:
>     > linux-libc-dev
>     > 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>     > [...]
>     >
>     > With this change, I would now have to add the explicit Build-
>     Depends on
>     > linux-libc-dev-${KERNEL_NAME} or the corresponding cross package.
>     That
>     > is a very ugly recipe API change that was also not documented.
>     >
>     > So, I'm not very happy with having this pattern here by default and
>     > would prefer only using it if there are actually multiple kernels
>     that
>     > also deploy their libc-dev packages.
>     >
>     > Unless someone has a good idea quickly, we should revert this
>     first and
>     > retry later.
>     >
> 
>     This is a design challenge: Do we really need per-KERNEL_NAME
>     linux-libc-dev packages, or is it enough to tell the users to enable
>     KERNEL_LIBC_DEV_DEPLOY only for one of them?
> 
> When a single apt feeds to support multiple BSP's with same or different
> architecture for a linux-libc-dev package, without this change we may
> not be able to support them.

If BSPs are breaking the UAPIs of each other, then we may not even
consider them valid BSPs (they should not change the UAPI at all, in
theory) - but I agree that this case is imaginable.

> 
>     I think that in way of 90% of the use cases the latter will be enough
>     because the kernels only differ in configuration or in patches that do
>     not create conflicting changes to the UAPI headers. But can someone
>     think of a case where this is not enough?
> 
> 
> Yes. I agree UAPI headers might be common in 99% cases unless we have
> specific BSP changes pushed and maintained

So, any ideas how to model a recipe API where you can opt-in to build
multiple linux-libc-dev (which will no longer be simple replacements of
the upstream packages)?

Or do you have any idea how to fix the issue that the sbuild envs are
not up/downgrading the linux-libc-dev packages anymore when they have
different names?

Reverting all this is not nice as well because we already broke the
recipe API, but it's currently the only good option I see.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/57ea3343-a94b-49d9-9bdd-b4cace7c5f03%40siemens.com.