Hi folks,
I'm looking a defect about out-of-tree kernel module in multilib build.
I'm building hello-mod package to run my test. During my test, I found
module-split generates kernel-module-hello package (naming style is
"kernel-module-" + ${moudle_name}). And, the real kernel module file is
included in this package.
So, is this right or expected behavior to have kernel module package
named with module name (kernel-module-hello) rather than the package
name (kernel-module-hello-mod)? Isn't the multilib name, and 'regular'
name for a kernel module package supposed to be identical?
But, for making multilib build happy, we need kernel-module-hello-mod
package (naming style is "kernel-module-${PN}). Actually, it's a empty
package (hello-mod or kernel-module-hello-mod). So, in hello-mod case,
we need both:
kernel-module-hello-0.1-r0.4.intel_xeon_core.rpm
kernel-module-hello-mod-0.1-r0.4.intel_xeon_core.rpm
As we known, the workaround is to rename the package name to
"kernel-module-" + ${PN} in hello-mod bb file otherwise multilib needs
${mlib}-hello-mod package, i.e. lib32-hello-mod.
I'm not quite sure if this is a real fix or just a workaround? If it's
not a real fix, how can we make multilib skip out-of-tree kernel module
package? What code should I look into?
How are in-tree kernel modules skipped by multilib? Just because their
names start with "kernel-module-"?
If we can't suppose multilib name, and 'regular' name for a kernel
module package are identical, the workaround may sound like a real fix.
Thanks,
Yang
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
