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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246390):
https://lists.openembedded.org/g/openembedded-core/message/246390
Mute This Topic: https://lists.openembedded.org/mt/121365625/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
