[PATCH 0/2] Fix kernel complementary package installation

[PATCH 0/2] Fix kernel complementary package installation

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Recipes usually name the standard packages based on PN. However, the kernel
uses ${KERNEL_PACKAGE_NAME} as the base name for its packages. This causes
inconsistent -src package naming and prevents complementary package
installation from finding the expected kernel packages. For example, a kernel
can produce kernel-dbg and linux-yocto-src, causing rootfs-dbg to include the
linux-yocto-src package but not kernel-dbg.

Introduce PACKAGE_BASENAME so recipes whose package names are based on
something other than PN can generate consistent -src package names and expose
the base name in pkgdata. Update oe-pkgdata-util to use PACKAGE_BASENAME when
resolving complementary package globs, with a fallback to PN for existing
pkgdata.

This is one possible way to handle the kernel-specific package naming. Other
approaches may be possible too. Some ideas:

- Do we really need this KERNEL_PACKAGE_NAME special feature for kernel
  packages? Or would it be possible to stick to ${PN} as any other recipe
  does?
- Is installing the kernel's complementary packages via standard
  complementary package installation the right mechanism for kernel
  packages? Or should there be a different mechanism which is more in line
  with how the kernel usually gets installed where installing it into the
  rootfs as a package is only one way out of many.

Adrian Freihofer (2):
  package: introduce PACKAGE_BASENAME for consistent kernel -src naming
  oe-pkgdata-util: use PACKAGE_BASENAME for glob PN-substitution
    fallback

 meta/classes-global/package.bbclass | 2 +-
 meta/classes-recipe/kernel.bbclass  | 3 +++
 meta/conf/bitbake.conf              | 6 ++++++
 meta/lib/oe/package.py              | 4 +++-
 scripts/oe-pkgdata-util             | 7 ++++++-
 5 files changed, 19 insertions(+), 3 deletions(-)

-- 
2.55.0

[PATCH 1/2] package: introduce PACKAGE_BASENAME for consistent kernel -src naming

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

populate_packages() always names the auto-generated -src package after
PN. kernel.bbclass instead names all its other sub-packages
(kernel-dbg, kernel-dev, kernel-modules, ...) after KERNEL_PACKAGE_NAME,
so the kernel recipe ended up with a lone -src package (linux-yocto-src)
that did not match the rest of the kernel-* family (e.g. kernel-dbg).

The complementary package install logic (oe-pkgdata-util) cannot find
packages that are not named after PN (${PN}-src, ${PN}-dbg, etc). For
the kernel recipe this meant linux-yocto-src was picked up, but
kernel-dbg, kernel-dev, etc. were not, which was inconsistent.

This commit introduces a generic PACKAGE_BASENAME variable
(default "${PN}") that a recipe/bbclass can override to declare the base
name its sub-packages should share. populate_packages() now uses it for
-src naming, and kernel.bbclass sets it to "${KERNEL_PACKAGE_NAME}". As
a result the kernel packages are now named kernel-dbg, kernel-src and so
on.
Changing the kernel's -src package to kernel-src also means this package
is longer found either by the complementary package installation and not
installed anymore.

If kernel packages should be installed via complementary package install
logic is left for a follow up commit. This commit only aligns the
package naming also for the -src package.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 meta/classes-recipe/kernel.bbclass | 3 +++
 meta/conf/bitbake.conf             | 6 ++++++
 meta/lib/oe/package.py             | 4 +++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
index 0a6d754108..16745557f7 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -679,6 +679,9 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
 # kernel-base becomes kernel-${KERNEL_VERSION}
 # kernel-image becomes kernel-image-${KERNEL_VERSION}
 PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
+# Keep the auto-generated -src package (see populate_packages() in oe/package.py) named,
+# and resolvable by tools like oe-pkgdata-util, consistently with the rest of the kernel-* family.
+PACKAGE_BASENAME = "${KERNEL_PACKAGE_NAME}"
 FILES:${PN} = ""
 FILES:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_MODULE_INSTALL_PREFIX}/modules.order ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin.modinfo"
 FILES:${KERNEL_PACKAGE_NAME}-image = ""
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d353a7cd2c..f82ee0f039 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -334,6 +334,12 @@ SOLIBSDEV:mingw32 = ".dll"
 
 PACKAGE_DEBUG_SPLIT_STYLE ?= "debug-with-srcpkg"
 
+# The base name recipe sub-packages (-dbg, -dev, -src etc.) are derived from.
+# Recipes/bbclasses that name their packages after something other than PN
+# (e.g. kernel.bbclass and KERNEL_PACKAGE_NAME) should override this so that
+# tooling (e.g. oe-pkgdata-util) can still map generic package globs to them.
+PACKAGE_BASENAME ??= "${PN}"
+
 PACKAGE_BEFORE_PN ?= ""
 PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
 PACKAGES_DYNAMIC = "^${PN}-locale-.*"
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index b7030643d2..4afd047905 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -1391,7 +1391,9 @@ def populate_packages(d):
     # If debug-with-srcpkg mode is enabled then add the source package if it
     # doesn't exist and add the source file contents to the source package.
     if split_source_package:
-        src_package_name = ('%s-src' % d.getVar('PN'))
+        # PACKAGE_BASENAME lets bbclasses (e.g. kernel.bbclass via KERNEL_PACKAGE_NAME)
+        # that name their other sub-packages differently from PN keep -src consistent with them.
+        src_package_name = ('%s-src' % (d.getVar('PACKAGE_BASENAME') or pn))
         if not src_package_name in packages:
             packages.append(src_package_name)
         d.setVar('FILES:%s' % src_package_name, '/usr/src/debug')
-- 
2.55.0

RE: [OE-core] [PATCH 1/2] package: introduce PACKAGE_BASENAME for consistent kernel -src naming

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Adrian Freihofer via lists.openembedded.org
> Sent: den 21 september 2026 23:51
> To: openembedded-core@lists.openembedded.org
> Cc: Adrian Freihofer <adrian.freihofer@siemens.com>
> Subject: [OE-core] [PATCH 1/2] package: introduce PACKAGE_BASENAME for consistent kernel -src naming
> 
> From: Adrian Freihofer <adrian.freihofer@siemens.com>
> 
> populate_packages() always names the auto-generated -src package after
> PN. kernel.bbclass instead names all its other sub-packages
> (kernel-dbg, kernel-dev, kernel-modules, ...) after KERNEL_PACKAGE_NAME,
> so the kernel recipe ended up with a lone -src package (linux-yocto-src)
> that did not match the rest of the kernel-* family (e.g. kernel-dbg).
> 
> The complementary package install logic (oe-pkgdata-util) cannot find
> packages that are not named after PN (${PN}-src, ${PN}-dbg, etc). For
> the kernel recipe this meant linux-yocto-src was picked up, but
> kernel-dbg, kernel-dev, etc. were not, which was inconsistent.
> 
> This commit introduces a generic PACKAGE_BASENAME variable
> (default "${PN}") that a recipe/bbclass can override to declare the base
> name its sub-packages should share. populate_packages() now uses it for
> -src naming, and kernel.bbclass sets it to "${KERNEL_PACKAGE_NAME}". As
> a result the kernel packages are now named kernel-dbg, kernel-src and so on.
> Changing the kernel's -src package to kernel-src also means this package
> is longer found either by the complementary package installation and not
> installed anymore.
> 
> If kernel packages should be installed via complementary package install
> logic is left for a follow up commit. This commit only aligns the
> package naming also for the -src package.
> 
> Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
> ---
>  meta/classes-recipe/kernel.bbclass | 3 +++
>  meta/conf/bitbake.conf             | 6 ++++++
>  meta/lib/oe/package.py             | 4 +++-
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-
> recipe/kernel.bbclass
> index 0a6d754108..16745557f7 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -679,6 +679,9 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel
> do_transform_bundled_initramfs d
>  # kernel-base becomes kernel-${KERNEL_VERSION}
>  # kernel-image becomes kernel-image-${KERNEL_VERSION}
>  PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
> +# Keep the auto-generated -src package (see populate_packages() in oe/package.py) named,
> +# and resolvable by tools like oe-pkgdata-util, consistently with the rest of the kernel-* family.
> +PACKAGE_BASENAME = "${KERNEL_PACKAGE_NAME}"
>  FILES:${PN} = ""
>  FILES:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_MODULE_INSTALL_PREFIX}/modules.order ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin.modinfo"
>  FILES:${KERNEL_PACKAGE_NAME}-image = ""
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index d353a7cd2c..f82ee0f039 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -334,6 +334,12 @@ SOLIBSDEV:mingw32 = ".dll"
> 
>  PACKAGE_DEBUG_SPLIT_STYLE ?= "debug-with-srcpkg"
> 
> +# The base name recipe sub-packages (-dbg, -dev, -src etc.) are derived from.

But that isn't really true, is it? E.g., PACKAGES below is defined 
based on ${PN} rather than ${PACKAGE_BASENAME}, and so are all the 
FILES variables. This seems more like a band-aid than a complete 
solution. (And no, I am not suggesting to change ${PN} to 
${PACKAGE_BASENAME} throughout the code because that would be 
madness.)

> +# Recipes/bbclasses that name their packages after something other than PN
> +# (e.g. kernel.bbclass and KERNEL_PACKAGE_NAME) should override this so that
> +# tooling (e.g. oe-pkgdata-util) can still map generic package globs to them.
> +PACKAGE_BASENAME ??= "${PN}"
> +
>  PACKAGE_BEFORE_PN ?= ""
>  PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
>  PACKAGES_DYNAMIC = "^${PN}-locale-.*"
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
> index b7030643d2..4afd047905 100644
> --- a/meta/lib/oe/package.py
> +++ b/meta/lib/oe/package.py
> @@ -1391,7 +1391,9 @@ def populate_packages(d):
>      # If debug-with-srcpkg mode is enabled then add the source package if it
>      # doesn't exist and add the source file contents to the source package.
>      if split_source_package:
> -        src_package_name = ('%s-src' % d.getVar('PN'))
> +        # PACKAGE_BASENAME lets bbclasses (e.g. kernel.bbclass via KERNEL_PACKAGE_NAME)
> +        # that name their other sub-packages differently from PN keep -src consistent with them.
> +        src_package_name = ('%s-src' % (d.getVar('PACKAGE_BASENAME') or pn))
>          if not src_package_name in packages:
>              packages.append(src_package_name)
>          d.setVar('FILES:%s' % src_package_name, '/usr/src/debug')
> --
> 2.55.0

//Peter

Re: [OE-core] [PATCH 1/2] package: introduce PACKAGE_BASENAME for consistent kernel -src naming

[Richard Purdie]

On Tue, 2026-09-22 at 17:09 +0000, Peter Kjellerstedt via lists.openembedded.org wrote:
> 
> But that isn't really true, is it? E.g., PACKAGES below is defined 
> based on ${PN} rather than ${PACKAGE_BASENAME}, and so are all the 
> FILES variables. This seems more like a band-aid than a complete 
> solution. (And no, I am not suggesting to change ${PN} to 
> ${PACKAGE_BASENAME} throughout the code because that would be 
> madness.)

PN is really the recipe name so it should be RN too!

Cheers,

Richard

[PATCH 2/2] oe-pkgdata-util: use PACKAGE_BASENAME for glob PN-substitution fallback

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Fix the complementary package install logic (oe-pkgdata-util) for
packages which have PACKAGE_BASENAME != PN  (only the kernel).

Add PACKAGE_BASENAME to PKGDATA_VARS so it is recorded in pkgdata like
any other per-package field, and have glob() read it (falling back to
PN, for pkgdata not yet regenerated with the new field) instead of PN
alone.

With this change the kernel -dbg and -src packages are automatically
added to the rootfs-dbg if the kernel is installed in the rootfs.
Removing this kernel packages is possible by
  PACKAGE_EXCLUDE_COMPLEMENTARY += "kernel-*"

Adding the kernel-dbg, -src packges for systems where the kernel is not
installed into the rootfs is possible via IMAGE_INSTALL_DEBUGFS.

Not sure, if there could be a more systaibable fix which would remove
KERNEL_PACKAGE_NAME from the kernel and not need this extra complexity
in the packaging code.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 meta/classes-global/package.bbclass | 2 +-
 scripts/oe-pkgdata-util             | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/classes-global/package.bbclass b/meta/classes-global/package.bbclass
index e21350a06f..4ead147cd3 100644
--- a/meta/classes-global/package.bbclass
+++ b/meta/classes-global/package.bbclass
@@ -385,7 +385,7 @@ EXPORT_FUNCTIONS package_name_hook
 
 PKGDESTWORK = "${WORKDIR}/pkgdata"
 
-PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE DESCRIPTION SUMMARY RDEPENDS RPROVIDES RRECOMMENDS RSUGGESTS RREPLACES RCONFLICTS SECTION PKG ALLOW_EMPTY FILES CONFFILES FILES_INFO PACKAGE_ADD_METADATA pkg_postinst pkg_postrm pkg_preinst pkg_prerm"
+PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE DESCRIPTION SUMMARY RDEPENDS RPROVIDES RRECOMMENDS RSUGGESTS RREPLACES RCONFLICTS SECTION PKG ALLOW_EMPTY FILES CONFFILES FILES_INFO PACKAGE_ADD_METADATA PACKAGE_BASENAME pkg_postinst pkg_postrm pkg_preinst pkg_prerm"
 
 python emit_pkgdata() {
     import oe.packagedata
diff --git a/scripts/oe-pkgdata-util b/scripts/oe-pkgdata-util
index acefae24f3..466086f009 100755
--- a/scripts/oe-pkgdata-util
+++ b/scripts/oe-pkgdata-util
@@ -86,11 +86,16 @@ def glob(args):
                 return os.path.join(args.pkgdata_dir, "runtime", pkgn)
             def readpn(pkgdata_file):
                 pn = ""
+                basename = ""
                 with open(pkgdata_file, 'r') as f:
                     for line in f:
                         if line.startswith("PN:"):
                             pn = line.split(': ')[1].rstrip()
-                return pn
+                        elif line.startswith("PACKAGE_BASENAME:"):
+                            basename = line.split(': ')[1].rstrip()
+                # PACKAGE_BASENAME lets a recipe (e.g. via kernel.bbclass's
+                # KERNEL_PACKAGE_NAME) name its sub-packages differently from PN
+                return basename or pn
             def readrenamed(pkgdata_file):
                 renamed = ""
                 pn = os.path.basename(pkgdata_file)
-- 
2.55.0

Re: [OE-core] [PATCH 0/2] Fix kernel complementary package installation

[Bruce Ashfield]

Thanks for digging into this. I am curious as to what is the use case
or configuration that you have where this became an issue ? I'm not
challenging the question, I'm just curious as you've explained it well
.. but didn't say how you ran into it.

The question is real: the kernel emits kernel-dbg/kernel-dev/... after
KERNEL_PACKAGE_NAME but the auto -src package lands as ${PN}-src
(i.e. linux-yocto-src), so the family is inconsistent: the PN-named
-src gets pulled into rootfs-dbg but the KERNEL_PACKAGE_NAME-named
kernel-dbg doesn't ... you end up with kernel source and no debug
symbols.  No argument there.

Where I want to discuss is the direction of the fix, and it is just
what you are asking. I'm not only saying this because you asked, since
I immediately thought it on reading the series :)

At the risk of repeating what you know already, let me summarize for
the mailing list archive. The kernel isn't really a normal rootfs
package, and I don't think we want it behaving as a complementary
one. On most of our targets the kernel isn't installed into the rootfs
at all (as you said) it's deployed by the bootloader / to a boot
partition, and installing kernel-image into '/' is just one model out
of several.

Riding the generic *-dbg/*-src completion machinery to pull kernel
debug/src into rootfs-dbg fits the recipes that live in the rootfs,
but I think it's the wrong thing for the kernel. I'd rather debug/src
for the kernel be delivered by a purpose-built path (the kernel
already has its own special install handling) than teach
oe-pkgdata-util and pkgdata to special-case it.

So:

- Patch 2 (PACKAGE_BASENAME into PKGDATA_VARS + oe-pkgdata-util glob)
  is the part I'd push back on. Its whole purpose is to make the
  kernel participate in complementary install, which is exactly what I
  don't think we should be doing. A dedicated kernel debug/src
  mechanism removes the need for it.

- Patch 1's underlying point: -src should be consistent with the rest
  of the kernel-* family, is fair on its own. But I'd rather not
  introduce a new global PACKAGE_BASENAME variable that every recipe
  now carries just to fix the kernel. kernel.bbclass already names
  every other sub-package after KERNEL_PACKAGE_NAME; if we want the
  -src name aligned, do it locally there, not with a tree-wide
  indirection.

There's also an interaction to be aware of. Vincent Davis had sent
(and you may have read it) a series ("[PATCH v4 xx/27] ... globally
define KERNEL_PACKAGE_NAME") that makes KERNEL_PACKAGE_NAME variable
across the tree for multi-kernel builds. Your PACKAGE_BASENAME is
defined *as* KERNEL_PACKAGE_NAME, so the two are coupled.  We'd end
up with two variables both encoding "the kernel's package base name,"
threaded through packaging, pkgdata, and pkgdata-util, and each series
would have to reconcile the other.

That's probably the opposite of where we want kernel packaging
complexity to go.

My ask: let's not merge this independently. The kernel package-naming
story, the -src consistency, whether debug/src rides complementary
install, and Vincent's KERNEL_PACKAGE_NAME variability, should
converge into one coherent design, and the goal for that design should
be *less* complexity in the kernel packaging path, not more.

Happy to help with that. But as usual, I'll defer to RP if he thinks
this is ok independently of if the kernel should be in the
complementary package mechanisms. I've never looked at the much, so
I don't have all the history behind them.

Bruce

Re: [OE-core] [PATCH 0/2] Fix kernel complementary package installation

[Richard Purdie]

On Mon, 2026-09-21 at 17:44 -0700, Bruce Ashfield via lists.openembedded.org wrote:
> Thanks for digging into this. I am curious as to what is the use case
> or configuration that you have where this became an issue ? I'm not
> challenging the question, I'm just curious as you've explained it well
> .. but didn't say how you ran into it.
> 
> The question is real: the kernel emits kernel-dbg/kernel-dev/... after
> KERNEL_PACKAGE_NAME but the auto -src package lands as ${PN}-src
> (i.e. linux-yocto-src), so the family is inconsistent: the PN-named
> -src gets pulled into rootfs-dbg but the KERNEL_PACKAGE_NAME-named
> kernel-dbg doesn't ... you end up with kernel source and no debug
> symbols.  No argument there.
> 
> Where I want to discuss is the direction of the fix, and it is just
> what you are asking. I'm not only saying this because you asked, since
> I immediately thought it on reading the series :)
> 
> At the risk of repeating what you know already, let me summarize for
> the mailing list archive. The kernel isn't really a normal rootfs
> package, and I don't think we want it behaving as a complementary
> one. On most of our targets the kernel isn't installed into the rootfs
> at all (as you said) it's deployed by the bootloader / to a boot
> partition, and installing kernel-image into '/' is just one model out
> of several.
> 
> Riding the generic *-dbg/*-src completion machinery to pull kernel
> debug/src into rootfs-dbg fits the recipes that live in the rootfs,
> but I think it's the wrong thing for the kernel. I'd rather debug/src
> for the kernel be delivered by a purpose-built path (the kernel
> already has its own special install handling) than teach
> oe-pkgdata-util and pkgdata to special-case it.
> 
> So:
> 
> - Patch 2 (PACKAGE_BASENAME into PKGDATA_VARS + oe-pkgdata-util glob)
>   is the part I'd push back on. Its whole purpose is to make the
>   kernel participate in complementary install, which is exactly what I
>   don't think we should be doing. A dedicated kernel debug/src
>   mechanism removes the need for it.
> 
> - Patch 1's underlying point: -src should be consistent with the rest
>   of the kernel-* family, is fair on its own. But I'd rather not
>   introduce a new global PACKAGE_BASENAME variable that every recipe
>   now carries just to fix the kernel. kernel.bbclass already names
>   every other sub-package after KERNEL_PACKAGE_NAME; if we want the
>   -src name aligned, do it locally there, not with a tree-wide
>   indirection.
> 
> There's also an interaction to be aware of. Vincent Davis had sent
> (and you may have read it) a series ("[PATCH v4 xx/27] ... globally
> define KERNEL_PACKAGE_NAME") that makes KERNEL_PACKAGE_NAME variable
> across the tree for multi-kernel builds. Your PACKAGE_BASENAME is
> defined *as* KERNEL_PACKAGE_NAME, so the two are coupled.  We'd end
> up with two variables both encoding "the kernel's package base name,"
> threaded through packaging, pkgdata, and pkgdata-util, and each series
> would have to reconcile the other.
> 
> That's probably the opposite of where we want kernel packaging
> complexity to go.
> 
> My ask: let's not merge this independently. The kernel package-naming
> story, the -src consistency, whether debug/src rides complementary
> install, and Vincent's KERNEL_PACKAGE_NAME variability, should
> converge into one coherent design, and the goal for that design should
> be *less* complexity in the kernel packaging path, not more.
> 
> Happy to help with that. But as usual, I'll defer to RP if he thinks
> this is ok independently of if the kernel should be in the
> complementary package mechanisms. I've never looked at the much, so
> I don't have all the history behind them.

I have some further thoughts. 

* The ${PN}-XXX naming convention is important as it gives users some
kind of handle on where sources for something are. If we rename
everything, it causes more confusion as names match until they don't.
Do we want to break more of our slightly consistent pieces?

* The reason for KERNEL_PACKAGE_NAME was to allow multiple kernel
builds and to allow them to be parallel installed. This is primarily
for kernel-module-XXX style names but PN should be unique in the first
place. The intent was not "name PN not exist" but "make two kernel
builds not clash". For that reason, do we actually need to rename PN-
src? Perhaps -dbg shouldn't be renamed instead?

* Did you think about setting PKG:${KERNEL_PACKAGE_NAME}-src ? That is
an existing mechanism allowing it to be renamed on target whilst the
build system would retain some consistency.

I do agree with Bruce that injecting a general mechanism like this into
the global recipe functionality is potentially problematic. We already
have one "rename" output mechanism through PKG, I'm not sure I want to
add another in the global 'recipespace'.

Cheers,

Richard

Re: [OE-core] [PATCH 0/2] Fix kernel complementary package installation

[Freihofer, Adrian]

Hi Bruce, hi Richard

On Tue, 2026-09-22 at 10:02 +0100, Richard Purdie wrote:
> On Mon, 2026-09-21 at 17:44 -0700, Bruce Ashfield via
> lists.openembedded.org wrote:
> > Thanks for digging into this. I am curious as to what is the use
> > case
> > or configuration that you have where this became an issue ? I'm not
> > challenging the question, I'm just curious as you've explained it
> > well

If you are using a debugger that can handle both user space and kernel
space seamlessly as demonstrated in this older
presentationhttps://repo.lauterbach.com/video/tut-e_linux-debug_slides.pdf
you will need a rootfs-dbg along with kernel sources when debugging a
user-space task.

> > .. but didn't say how you ran into it.
> > 
> > The question is real: the kernel emits kernel-dbg/kernel-dev/...
> > after
> > KERNEL_PACKAGE_NAME but the auto -src package lands as ${PN}-src
> > (i.e. linux-yocto-src), so the family is inconsistent: the PN-named
> > -src gets pulled into rootfs-dbg but the KERNEL_PACKAGE_NAME-named
> > kernel-dbg doesn't ... you end up with kernel source and no debug
> > symbols.  No argument there.

In the meantime, Richard explained why it is as it is: there is one
source package which can be used together with multiple different
binary packages derived from that source. Given that context, the
naming makes sense.

> > 
> > Where I want to discuss is the direction of the fix, and it is just
> > what you are asking. I'm not only saying this because you asked,
> > since
> > I immediately thought it on reading the series :)
> > 
> > At the risk of repeating what you know already, let me summarize
> > for
> > the mailing list archive. The kernel isn't really a normal rootfs
> > package, and I don't think we want it behaving as a complementary
> > one. On most of our targets the kernel isn't installed into the
> > rootfs
> > at all (as you said) it's deployed by the bootloader / to a boot
> > partition, and installing kernel-image into '/' is just one model
> > out
> > of several.
> > 
> > Riding the generic *-dbg/*-src completion machinery to pull kernel
> > debug/src into rootfs-dbg fits the recipes that live in the rootfs,
> > but I think it's the wrong thing for the kernel. I'd rather
> > debug/src
> > for the kernel be delivered by a purpose-built path (the kernel
> > already has its own special install handling) than teach
> > oe-pkgdata-util and pkgdata to special-case it.
> > 
> > So:
> > 
> > - Patch 2 (PACKAGE_BASENAME into PKGDATA_VARS + oe-pkgdata-util
> > glob)
> >   is the part I'd push back on. Its whole purpose is to make the
> >   kernel participate in complementary install, which is exactly
> > what I
> >   don't think we should be doing. A dedicated kernel debug/src
> >   mechanism removes the need for it.
> > 
> > - Patch 1's underlying point: -src should be consistent with the
> > rest
> >   of the kernel-* family, is fair on its own. But I'd rather not
> >   introduce a new global PACKAGE_BASENAME variable that every
> > recipe
> >   now carries just to fix the kernel. kernel.bbclass already names
> >   every other sub-package after KERNEL_PACKAGE_NAME; if we want the
> >   -src name aligned, do it locally there, not with a tree-wide
> >   indirection.

Based on the feedback here, I’ve concluded that we should disable the
kernel's complementary install logic. This ensures the source package
isn't installed automatically without the corresponding debugging
symbols. Additionally, we should keep the package naming as it is.

> > 
> > There's also an interaction to be aware of. Vincent Davis had sent
> > (and you may have read it) a series ("[PATCH v4 xx/27] ... globally
> > define KERNEL_PACKAGE_NAME") that makes KERNEL_PACKAGE_NAME
> > variable
> > across the tree for multi-kernel builds. Your PACKAGE_BASENAME is
> > defined *as* KERNEL_PACKAGE_NAME, so the two are coupled.  We'd end
> > up with two variables both encoding "the kernel's package base
> > name,"
> > threaded through packaging, pkgdata, and pkgdata-util, and each
> > series
> > would have to reconcile the other.

Thank you for the pointer to the series. This could potentially solve a
few more issues, but I'm not sure how actively the series is still
being maintained.

> > 
> > That's probably the opposite of where we want kernel packaging
> > complexity to go.
> > 
> > My ask: let's not merge this independently. The kernel package-
> > naming
> > story, the -src consistency, whether debug/src rides complementary
> > install, and Vincent's KERNEL_PACKAGE_NAME variability, should
> > converge into one coherent design, and the goal for that design
> > should
> > be *less* complexity in the kernel packaging path, not more.
> > 
> > Happy to help with that. But as usual, I'll defer to RP if he
> > thinks
> > this is ok independently of if the kernel should be in the
> > complementary package mechanisms. I've never looked at the much, so
> > I don't have all the history behind them.
> 
> I have some further thoughts. 
> 
> * The ${PN}-XXX naming convention is important as it gives users some
> kind of handle on where sources for something are. If we rename
> everything, it causes more confusion as names match until they don't.
> Do we want to break more of our slightly consistent pieces?
> 
> * The reason for KERNEL_PACKAGE_NAME was to allow multiple kernel
> builds and to allow them to be parallel installed. This is primarily
> for kernel-module-XXX style names but PN should be unique in the
> first
> place. The intent was not "name PN not exist" but "make two kernel
> builds not clash". For that reason, do we actually need to rename PN-
> src? Perhaps -dbg shouldn't be renamed instead?

Thank you for the additional context. I agree that the package names
are correct. We just need to refine the complementary package mechanism
for the kernel packages to achieve a more consistent and useful
implementation. Probably something different than the available
complementary package installation mechanism as Bruce suggested too.

> 
> * Did you think about setting PKG:${KERNEL_PACKAGE_NAME}-src ? That
> is
> an existing mechanism allowing it to be renamed on target whilst the
> build system would retain some consistency.
> 
> I do agree with Bruce that injecting a general mechanism like this
> into
> the global recipe functionality is potentially problematic. We
> already
> have one "rename" output mechanism through PKG, I'm not sure I want
> to
> add another in the global 'recipespace'.
> 
> Cheers,
> 
> Richard
> 
> 
I'll investigate a way to install these packages into the rootfs-dbg
without requiring changes to the kernel packaging.

Thank you for the explanation.
Regards,
Adrian