[yocto] Removing rootfs from SDK

[Paul Eggleton]

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