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

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Thu, Oct 30, 2026 at 6:40 AM Freihofer, Adrian wrote:
>
> > First, to make sure I have the use case right: this is TRACE32 (or
> > cross-gdb to qemu, it's a similar pattern) running on the host, with
> > rootfs-dbg extracted on the host as the debug sysroot. Nothing here
> > runs gdb on the target. Correct ?
>
> Yes, that's the use case which triggered this discussion.
>
> But I can think about more use cases which could benefit from a
> complete -src package (or different package name) for the kernel as
> there are also more use cases for any other -src package.

Thanks for confirming. I'd like to hear what those other use cases are,
since they're what would drive a full source package (more on that below).

For the host-side case, though, I don't think we need a source package
at all. The debugger runs on the host, so rootfs-dbg only has to supply
the symbols (kernel-dbg, kernel-vmlinux). The source can come from any
tree on the host that matches the build: the build's
work-shared/<machine>/kernel-source, or a linux-yocto checkout at the
recipe's SRCREV. With the prefix map change, every path in the kernel's
debug info is under /usr/src/kernel, so it's a single mapping in the
debugger to that tree.

> >    I'm not completely sold on sending this one yet, but I could be
> >    convinced to go that way rather than a -src package. If it covers
> >    your use case, that's the argument that would do it.
>
> I think this sounds very good and it would address at least the remote
> debugging case and make it much more consistent than it is now.

Having thought about it more, I'm going to keep linux-source local for
now. The problem is that a full source tree plus the ${B} artifacts is a
superset of kernel-devsrc. Everything devsrc does can be done with it,
just with a bigger footprint. I don't want two copies of the kernel source
to maintain, one curated and one not, and that's what linux-source is.

If a use case arrives that needs the source inside a rootfs (and not just
on the host), I'd want it done inside kernel-devsrc: one tree at
/usr/src/kernel, curated by default as it is today, with an opt-in to
widen it to the full source. No second copy, and no path mapping at all,
since the debug info already points there. The source would need to be
its own package without devsrc's toolchain RDEPENDS, so rootfs-dbg can
take it without pulling in a compiler. And it stays opt-in: nobody should
get ~1.6GB of source by accident.

It also doesn't have to be the whole tree. devsrc is already machine
specific, so the likely way I'd go is a larger devsrc: a curated spine
(core plus the machine's arch), with the drivers it needs discovered
from what the build actually compiled. On qemux86-64 that's about 330MB,
versus 1.5GB for the full tree.

> >  - 2/3: fine with me. Keeping the kernel out of the complementary
> >    install is what I asked for in v1, and with (1) it is a no-op.
>
> Should we then not just drop this patch as well? It's ugly to have this
> kernel specific case handled outside of the kernel recipe.

Agreed, drop it. With the prefix map, linux-yocto-src isn't created at
all, so there's nothing for core-image to exclude. That makes it all three.

The way I see it now, the 592 generated files in linux-yocto-src are the
actual bug today. They're there only because ${B} isn't mapped, and
they're the only reason the kernel gets a -src package. Complementary
install then pulls that package into rootfs-dbg without kernel-dbg, which
is the inconsistency you started from. Fixing the map removes the package,
and so the inconsistency, without any kernel special case in the image
classes or package.py.

> What the kernel recipe could provide instead:
> A: an empty -src package (just to behave like all other packages).
> B: an empty meta package which RDEPENDS on all the real kernel source
> packages. The kernel would no longer be something special. The sources
> are also included in the rootfs-dbg by default as for all user space
> packages. If the user prefers to have the kernel excluded from rootfs-
> dbg he can do what the patch does.
>
> I think B would be the most consistent approach and therefore also the
> most self-explanatory implementation.

I don't think we should do either.

A is an empty package that exists only so the kernel matches a pattern.
It doesn't give anyone anything.

For B, the real source package it would depend on doesn't exist (see
above). Even if it did, B puts the kernel back on the generic
complementary path, which is what I pushed back on in v1:

 - Complementary install maps every installed kernel-module-* package to
   linux-yocto-src, so almost every debug image would get the full kernel
   source by default, about 1.6GB unpacked.

 - It ties linux-yocto to whichever recipe ends up providing the source.

 - kernel-dbg still isn't pulled in by complementary install
   (KERNEL_PACKAGE_NAME vs PN), so you'd still get source without symbols.

The kernel is special here, in that it isn't usually a rootfs package.
I'd rather that be explicit (IMAGE_INSTALL_DEBUGFS for the symbols, and
a mapping to the source on the host) than hidden behind a meta-package.

So my plan is:

 - drop 1/3, 2/3 and 3/3
 - I'll send the kernel.bbclass prefix map change on its own, once I've
   checked SPDX's compiled-sources filter is unaffected (it's the only
   other consumer of the kernel's debugsources list)
 - revisit a full source package, inside kernel-devsrc, when there's a
   concrete use case that needs it in a rootfs

Thougts ?

Bruce