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