4069 2013-03-21 13:21:07 +0000 ptest files are packaged into core package 2013-04-11 11:46:50 +0000 1 1 7 Build System, Metadata & Runtime OE-Core deployment 1.4 All Multiple RESOLVED FIXED Medium+ normal 1.4 M6 1 bjst bjst richard.purdie sgw --- --- --- oldest_to_newest 30961 0 bjst 2013-03-21 13:21:07 +0000 (copied from oe-core list email 20130320083055.GQ31812@sestofb10.enea.se) The ${PN}-ptest group is not added to PACKAGES by default in bitbake.conf like all the other groups. Instead it is added to PACKAGES in ptest.bbclass. This way it is only added for those recipes that implement ptest. However it turns out this doesn't work when package splitting. Instead of putting ptest files into packages-split/${PN}-ptest, those files are put into the core ${PN} package which is obviously not what we want. I'm scratching my head a bit about why this happens, and would like help from people with deeper bitbake knowledge. I guess the splitting is somehow done outside the package scope, but why and how do we fix it? Putting ${PN}-ptest in PACKAGES in bitbake.conf "solves" this issue, but Richard Purdie was against that earlier since we yet have only a few "ptest enabled" packages. # find tmp/work/i586-poky-linux/bash -name run-ptest tmp/work/i586-poky-linux/bash/4.2-r6/image/usr/lib/bash/ptest/run-ptest tmp/work/i586-poky-linux/bash/4.2-r6/sysroot-destdir/usr/lib/bash/ptest/run-ptest tmp/work/i586-poky-linux/bash/4.2-r6/package/usr/lib/bash/ptest/run-ptest tmp/work/i586-poky-linux/bash/4.2-r6/run-ptest tmp/work/i586-poky-linux/bash/4.2-r6/packages-split/bash/usr/lib/bash/ptest/run-ptest We want is the last line to be: tmp/work/i586-poky-linux/bash/4.2-r6/packages-split/bash-ptest/usr/lib/bash/ptest/run-ptest 30978 1 bjst 2013-03-21 14:53:12 +0000 Aha, this is caused by ptest.bbclass doing: PACKAGES += "${PN}-ptest" instead of: PACKAGES =+ "${PN}-ptest" Unfortunately, the full solution is not quite that simple. But now I know enough to submit a patch. 30992 2 sgw 2013-03-21 15:42:14 +0000 Bjorn, I was just going to look at that this morning, looks like you found the trick, which is the PACKAGES list is greedy by nature, meaning things earlier in the list will match and remove them from consideration by packages later in the list. I guess I can close this bug then? 30996 3 bjst 2013-03-21 15:50:46 +0000 Yes, I just sent a patch with a proposed solution for this. Re: closing: Do we close bugs when a fix is found or when a fix is accepted? 31002 4 sgw 2013-03-21 16:59:02 +0000 Right, I will assign this back to you and you can mark it resolved when the patch is accepted, since this is a bug. I will pull this into MUT and queue it once we get M5 built. 31924 5 richard.purdie 2013-04-11 11:46:50 +0000 Patch was taken into master (http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=44120a053c0cf2c7134bb1ee29854dddf28e4cf8). Please open new bugs for any further issues.