public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'cedric.hombourger@siemens.com' via isar-users" <isar-users@googlegroups.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Kiszka, Jan" <jan.kiszka@siemens.com>,
	"Vadivel, Arulpandiyan" <arulpandiyan.vadivel@siemens.com>
Cc: "srikanth.krishnakar@siemens.com" <srikanth.krishnakar@siemens.com>
Subject: Re: [PATCH] linux-custom: support to add linux-libc-dev package with kernel name
Date: Thu, 11 Sep 2025 07:02:05 +0000	[thread overview]
Message-ID: <e35ea8da51b2262d809e18e54f5941a2b2d887e3.camel@siemens.com> (raw)
In-Reply-To: <6c32b82c-c2b6-42c0-b947-f0b3ee07fe93@siemens.com>

On Thu, 2025-09-11 at 07:11 +0200, 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
> > > > <arulpandiyan.vadivel@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.

Yes I am in favor.

> > 
> 
> 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?

This would break one of our multiconfig projects (and I am not
referring to our -distro project that you have seen) but a project
where we have several machines and two with vendor-specific headers
that are needed by downstream projects to build their userland
middleware/applications

Since Isar supports and advertises multiconfig (e.g. user manual
suggests using bitbake mc:*:isar-image-base), I believe we should make
sure recipe-level settings such as KERNEL_LIBC_DEV_DEPLOY will not
break.

It is surely not an easy task and clearly reinforces the need for more
tests with every submission we make.

> 
> 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?
> 
> Jan
> 

-- 
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/e35ea8da51b2262d809e18e54f5941a2b2d887e3.camel%40siemens.com.

      parent reply	other threads:[~2025-09-11  7:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 19:00 'Arulpandiyan Vadivel' via isar-users
2025-01-12 20:46 ` 'cedric.hombourger@siemens.com' via isar-users
2025-01-13  8:07   ` [PATCH V2] " 'Arulpandiyan Vadivel' via isar-users
2025-01-13 14:04     ` 'cedric.hombourger@siemens.com' via isar-users
2025-01-14 16:33       ` [PATCH V3] " 'Arulpandiyan Vadivel' via isar-users
2025-01-17 13:25         ` 'Jan Kiszka' via isar-users
2025-01-17 17:37           ` 'Arulpandiyan Vadivel' via isar-users
2025-01-17 17:40             ` 'Jan Kiszka' via isar-users
2025-01-17 17:44               ` 'Jan Kiszka' via isar-users
2025-01-17 17:59                 ` 'Arulpandiyan Vadivel' via isar-users
2025-01-17 18:02                 ` [PATCH V4] " 'Arulpandiyan Vadivel' via isar-users
2025-01-21  9:47                   ` [PATCH] " 'Arulpandiyan Vadivel' via isar-users
2025-02-06 11:50                     ` 'Vadivel, Arulpandiyan' via isar-users
2025-02-07  7:48                     ` Uladzimir Bely
2025-09-10 13:55                     ` 'Jan Kiszka' via isar-users
2025-09-10 17:22                       ` 'Jan Kiszka' via isar-users
2025-09-11  5:11                         ` 'Jan Kiszka' via isar-users
2025-09-11  5:21                           ` Arulpandiyan Vadivel
2025-09-11  5:28                             ` 'Jan Kiszka' via isar-users
2025-09-11  5:38                               ` Arulpandiyan Vadivel
2025-09-11  8:33                                 ` 'Jan Kiszka' via isar-users
2025-09-11 11:05                                   ` 'Jan Kiszka' via isar-users
2025-09-11 13:59                                     ` 'Jan Kiszka' via isar-users
2025-09-11  7:02                           ` 'cedric.hombourger@siemens.com' via isar-users [this message]

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=e35ea8da51b2262d809e18e54f5941a2b2d887e3.camel@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=arulpandiyan.vadivel@siemens.com \
    --cc=cedric.hombourger@siemens.com \
    --cc=jan.kiszka@siemens.com \
    --cc=srikanth.krishnakar@siemens.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox