5702 2014-01-03 14:37:19 +0000 Dependency on dbus-ptest-ptest increases image size significantly 2014-04-28 01:35:16 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.6 All Multiple RESOLVED FIXED Medium normal 1.6 1 bluelightning chong.lu bjst gabriel.barbu jacob.kroon lpapp meta.mr.watcher meta.watcher net147 richard.purdie --- Regression (Used to work) No (bug/feature does not impact docs) oldest_to_newest 39659 0 bluelightning 2014-01-03 14:37:19 +0000 Since we now have ptest in DISTRO_FEATURES in poky, there is now a hard dependency from the dbus package on dbus-ptest-ptest. In meta/recipes-core/dbus/dbus.inc we have: meta/recipes-core/dbus/dbus.inc:RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest', '', d)}" This means that any image that contains dbus, regardless of whether ptest-pkgs is in IMAGE_FEATURES, will get this package. dbus-ptest-ptest is 38MB here in my test environment which is a pretty egregious size increase for most small images. We need to find a way to not pull this package in by default even if ptest has to be enabled at the distro level. 39713 1 richard.purdie 2014-01-09 15:42:39 +0000 Shouldn't this be on the dbus-ptest package and not dbus? 39731 2 bluelightning 2014-01-10 09:41:16 +0000 Right, I think if we add a dummy ${PN}-ptest package to dbus.inc, set ALLOW_EMPTY on it, and then change the line referenced above to RDEPENDS_${PN}-ptest = ..., it should fix the problem since dbus-ptest should automatically be brought into the image when "ptest-pkgs" is in IMAGE_FEATURES and thus dbus-ptest-ptest will along with it. 39852 3 chong.lu 2014-01-16 10:20:27 +0000 solution 1: Add following code in dbus.inc: diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc index 86d6caa..0505fff 100644 --- a/meta/recipes-core/dbus/dbus.inc +++ b/meta/recipes-core/dbus/dbus.inc @@ -6,9 +6,12 @@ LICENSE = "AFL-2 | GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \ file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c" DEPENDS = "expat virtual/libintl" -RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest', '', d)} initscripts-functions" +RDEPENDS_dbus = "initscripts-functions" RDEPENDS_dbus_class-native = "" RDEPENDS_dbus_class-nativesdk = "" +PACKAGES += "dbus-ptest" +ALLOW_EMPTY_${PN}-ptest = "1" +RDEPENDS_${PN}-ptest = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-test', '', d)}" SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \ file://tmpdir.patch \ And rename dbus-ptest_1.6.18.bb to dbus-test_1.6.18.bb. Issue: When "ptest-pkgs" is in IMAGE_FEATURES and "ptest" is in DISTRO_FEATURES, dbus-test package is generated, but it doesn't install in image. solution 2: If I change RDEPENDS_${PN}-ptest = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-test', '', d)}" to RDEPENDS_${PN}-ptest = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-test-ptest', '', d)}", it's the same result with no patch. Any image that contains dbus, regardless of whether ptest-pkgs is in IMAGE_FEATURES, will get this package. Do you have any suggestion? 40817 4 lpapp 2014-03-03 04:27:37 +0000 Are there any near term plans to be moving forward with this? 40818 5 chong.lu 2014-03-03 05:51:06 +0000 In three recipes(dbus, dbus-glib, dbus-ptest), they have a circular dependency issue. So I have no way to merge dbus-ptest and dbus in one recipes. 40840 6 bluelightning 2014-03-03 16:15:15 +0000 Chong, the solutions being discussed don't involve merging the recipes together, so I'm a bit confused. Re solution 2 above, why is dbus-test-ptest pulled into the image unconditionally? I can understand why it would be built, but why would a runtime dependency be introduced? Could you please enable buildhistory and check the .dot dependency graphs to find out why? 40907 7 chong.lu 2014-03-06 06:06:43 +0000 I've patched to fix this, will send the patch to the oe-core list. 42743 8 gabriel.barbu 2014-04-18 14:40:14 +0000 Attempting to apply the patch proposed here: http://article.gmane.org/gmane.comp.handhelds.openembedded.core/50399 has the following results: While having ptest in DISTRO_FEATURES: - For images not having ptest-pkgs in IMAGE_FEATURES, dbus ptest is no longer installed/OK. - However, for images having ptest-pkgs in IMAGE_FEATURES, dbus ptest is not installed either/NOT OK. 42798 9 chong.lu 2014-04-21 01:59:14 +0000 (In reply to comment #8) > Attempting to apply the patch proposed here: > http://article.gmane.org/gmane.comp.handhelds.openembedded.core/50399 > has the following results: > While having ptest in DISTRO_FEATURES: > - For images not having ptest-pkgs in IMAGE_FEATURES, dbus ptest is no > longer installed/OK. > - However, for images having ptest-pkgs in IMAGE_FEATURES, dbus ptest is not > installed either/NOT OK. I test the situtation that images have ptest-pkgs in IMAGE_FEATURES and dbus ptest is installed in /usr/lib/dbus-test directory on target. 42810 10 gabriel.barbu 2014-04-22 09:22:12 +0000 That’s strange, for me it does not appear installed. Do you include the package in your image as "dbus" or something else, like "dbus-test"? 42811 11 chong.lu 2014-04-22 09:29:54 +0000 (In reply to comment #10) > That’s strange, for me it does not appear installed. Do you include the > package in your image as "dbus" or something else, like "dbus-test"? In my conf/local.conf, I add following lines: EXTRA_IMAGE_FEATURES += "ptest-pkgs" CORE_IMAGE_EXTRA_INSTALL += "dbus" And run "bitbake core-image-minimal", the dbus-test is installed. 42813 12 gabriel.barbu 2014-04-22 12:50:25 +0000 We have custom images based on using custom package groups. In this particular case we have a packagegroup-ptest which has all the packages needed (including dbus) in RDEPENDS_${PN}; this packagegroup is included in an image by IMAGE_INSTALL. With this mechanism, we get all ptests installed in the image rootfs/usr/lib, except dbus. I also tried your approach with EXTRA_IMAGE_FEATURES and CORE_IMAGE_EXTRA_INSTALL, and I still don’t get dbus in the image. But I see in the Yocto manual that “You can add packages using a similar approach through the CORE_IMAGE_EXTRA_INSTALL variable. If you use this variable, only core-image-* images are affected.” so maybe that’s why. I will try to investigate where the differences come from, as in principle the mechanisms should be equivalent. I’ll also try with standard core-images. Thanks 42816 13 bluelightning 2014-04-22 14:19:21 +0000 *** Bug 6203 has been marked as a duplicate of this bug. *** 43030 14 chong.lu 2014-04-28 01:35:16 +0000 fixed.