[yocto] Removing rootfs from SDK

[John Ernberg]

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.
>
> Cheers,
> Paul
>
Hi Paul

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.

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/[distro]/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?

Best regards // John Ernberg