[oe] Unwanted dependency on X from ppp

[Mats Kärrman]

Thank you Bob!

You're my hero, honestly!

The "clean build" time concerns me though. I will need bluez components,
but not gstreamer so I guess I'll set out to find a neat way to override
the default bluez recipe and get rid of that dependency.

// Mats

________________________________________     
From: openembedded-devel-bounces at lists.openembedded.org [openembedded-devel-bounces at lists.openembedded.org] on behalf of Bob Foerster [robert at erafx.com]
Sent: Wednesday, July 13, 2011 4:18 PM
To: openembedded-devel at lists.openembedded.org
Subject: Re: [oe] Unwanted dependency on X from ppp

Hi Mats,

On Wed, Jul 13, 2011 at 8:16 AM, Mats Kärrman <Mats.Karrman at tritech.se>wrote:

> Hi Everyone!
>
> I'm building a small "headless" embedded system with OE and the Angstrom
> distro. A normal rootfs build consists of about 1500 tasks. Everything fine
> so far.
>
> Now I wanted to include the ppp daemon in my build and thus just added
> "ppp" to IMAGE_INSTALL. Suddenly the rootfs build is about 4000 tasks and a
> lot of X/display related stuff is downloaded and built. I fail to see the
> connection.
>

Are the X/display items you're concerned about actually making it into the
final image, or just being built?  If they are ending up in the image, then
it will take some investigation as to why that's happening. If they're just
being built there is probably not much you can do, but the following may
help shed some light as to why they are built.

To understand why adding ppp pulls in various X/display packages, keep in
mind that what is downloaded and built does not directly correlate to what
ends up in the image.  Often, recipes may provide several packages which
have a broad set of build time dependencies, but these don't all necessarily
end up in the image.

For tracking down dependencies, you can fire up the dependency explorer gui
for bitbake:
bitbake -g -u depexp ppp

Doing this and following the trail, one sees:
ppp -> libpcap -> bluez-libs (here, bluez4 is selected as provider for
bluez-libs) -> gst-plugins-base -> gtk+ -> libx*

Given this dependency chain, we start to see why building ppp causes various
gtk+ and X packages to be built. The bluez4 recipe provides a package
gst-plugin-bluez, causing a build time dependency on gst-plugins-base.
 gst-plugins-base depends on many things, including gtk+.  As a result of
these dependencies, many packages end up being built.  The shlibs code in OE
automatically detects the run time libs required for a given package and
appropriately associates run time dependencies on them.  As such, unless one
adds gst-plugin-bluez to IMAGE_INSTALL, I wouldn't expect the various gtk+,
libx*, etc packages to make it into the final image.  If they are, then
there is another dependency that is pulling them into the image and needs
explored.  For a little bit more background on build vs run time
dependencies, see [1].

Hope that helps clarify a bit.
Bob

[1]
http://dominion.thruhere.net/koen/cms/reducing-the-size-of-your-angstrom-rootfs-without-changing-the-buildsystem



> I'm afraid I'm not using the latest trunk or release of OE but any
> suggestions or directions on how to find/eliminate the cause of the problem
> would be greatly appreciated!
>
> Best Regards,
> Mats
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel at lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel