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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246405): https://lists.openembedded.org/g/openembedded-core/message/246405 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]] -=-=-=-=-=-=-=-=-=-=-=-
