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

[Arulpandiyan Vadivel <arulcse2008@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 10048 bytes --]

I understand the issue reported , Can you please help to share/provide the 
steps to reproduce the issue where I can check for the solutions

Regards
Arulpandiyan V.

On Thursday, 11 September 2025 at 10:58:45 UTC+5:30 Jan Kiszka wrote:

> 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/4be9f176-71d2-4f61-bd98-70d91385574fn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 13937 bytes --]