On Tuesday 16 June 2015 14:05:15 John Ernberg wrote: > On 2015-06-15 10:59, Paul Eggleton wrote: > > On Monday 15 June 2015 05:39:24 John Ernberg wrote: > >> On 2015-06-12 14:43, Paul Eggleton wrote: > >>> On Thursday 04 June 2015 09:30:49 John Ernberg wrote: > >>>> We're trying to optimize the SDK generated by bitbake -c populate_sdk. > >>>> Currently we're trying to remove the kernel, modules and other > >>>> executables which we have no use for, most of it could be removed using > >>>> IMAGE_INSTALL = "" and IMAGE_FEATURES = "". > >>>> > >>>> Due to us using 2 different kernel module sets, we're using > >>>> IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are not > >>>> cleared by the IMAGE_INSTALL = "" setting. > >>>> > >>>> I've tried to do IMAGE_INSTALL_remove using the same variable that we > >>>> use to populate the IMAGE_INSTALL_append, but that doesn't work. I can > >>>> however remove each individual package added by IMAGE_INSTALL_append. > >>>> Due to the number of packages added by IMAGE_INSTALL_append this is not > >>>> really feasible. > >>>> > >>>> Is there a way to clear IMAGE_INSTALL_append without doing an > >>>> IMAGE_INSTALL_remove per package? Alternatively clearing it using a > >>>> python loop without needing to know the name of each package. > >>>> > >>>> We're also seeing busybox getting included into the SDK without > >>>> anything > >>>> showing a dependency on it from running bitbake -g -c populate_sdk. > >>>> > >>>> What could be going on with that? > >>> > >>> We construct the SDK for an image by getting a list of the packages in > >>> the > >>> image, and then including the -dev and -dbg packages that correspond to > >>> those in the host portion of the SDK. Thus if your image has busybox in > >>> it then you will get busybox-dev and busybox-dbg in your SDK. > >>> > >>> In the dizzy (1.7) and later releases, there is a > >>> PACKAGE_EXCLUDE_COMPLEMENTARY variable that can take a regex to match > >>> packages that you do not wish to install complementary packages for. You > >>> could set this in your image recipe. Note that this will affect all > >>> complementary package processing for the image as well as the SDK (e.g. > >>> dev-pkgs in IMAGE_FEATURES will also be affected, if you used that). > >> > >> I managed to clear out everything set by IMAGE_INSTALL and > >> IMAGE_FEATURES by setting PACKAGE_INSTALL = "". > >> So we no longer package the kernel etc into our SDK. > >> We do however still package the busybox binaries, when I run: > >> bitbake -e -c populate_sdk [image] | less > >> and then search for busybox, I get no results, so according to the > >> variables nothing adds busybox to the SDK. > >> I cannot figure out why busybox would get included, and I don't mean the > >> dev and dbg packages here, but the actual binary package. > > > > That'll be because the -dev package depends on the main package; > > meta/conf/bitbake.conf has the following line which sets up this > > dependency: > > > > RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})" > > > > You could set RDEPENDS_${PN}-dev = "" at the configuration level to > > disable this, or you could do it per recipe with bbappends. > > I just tried to apply this, combined with the PACKAGE_INSTALL solution, > it will not work, and throws a huge build error log. Removing the > PACKAGE_INSTALL solution and setting only the RDEPENDS solution in the > local.conf will have no effect on the SDK at all. Busybox is still > included, and it seems like all other binaries are back as well.
OK, that is not what I would expect - somehow there is still a dependency on those files. You may wish to enable buildhistory as described here and look at the dependency graphs it produces: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality It just occurred to me that if *any* of the packages you include in your SDK include shell scripts, rpm will pretty much insist that you have a provider of /bin/sh and that would be busybox, so that might also account for busybox being in there. I don't immediately know how you would exclude that. > An excerpt of the build log: > ERROR: Cannot get the package dependencies. Command > '[path-to-yocto-build-dir]/tmp/sysroots/x86_64-linux/usr/bin/rpmresolve > -t > [path-to-yocto-build-dir]/tmp/work/[machine-and-sdk]/1.0-r0/sdk/image/opt/[d > istro]/1.5+snapshot/sysroots/[target-arch]/var/lib/rpm' returned 1: > base-files|busybox > base-files|busybox > base-files|busybox > base-files|busybox > base-files|busybox > base-files|busybox > base-files|busybox > base-files|busybox > base-passwd|busybox > base-passwd-dev|libc6-dev [REC] > busybox|libc6 > busybox|update-alternatives-opkg > busybox|libc6 > busybox|libc6 > busybox|libc6 > busybox|libc6 > > And then the log continues similarly for several pages. What could have > gone wrong? I can't tell what could be wrong from just this start of the message - is there anything useful at the end? Also what exactly did you set PACKAGE_INSTALL to ? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto