Re: Unwanted dependency on X from ppp

[Bob Foerster <robert@erafx.com>]

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

> Thank you Bob!
>
> You're my hero, honestly!
>

No problem, happy to help!


> 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.
>
>
I would normally override this in my layer using amend.inc. You can probably
do it with bbappend too, but I'm not too familiar with that.

The basic idea to remove that dependency would be to override/modify
bluez4.inc (or any other offending files):
 - remove gst-plugins-base from DEPENDS so gstreamer and all dependencies
don't get built
 - fix configuring/compiling of the package after removing the dependency
(like modify EXTRA_OECONF to get rid of the enable gstreamer switch)

That may not be all that needs done, but that should at least get you on the
right track.

Enjoy!
Bob

// Mats
>
> ________________________________________
> From: openembedded-devel-bounces@lists.openembedded.org [
> openembedded-devel-bounces@lists.openembedded.org] on behalf of Bob
> Foerster [robert@erafx.com]
> Sent: Wednesday, July 13, 2011 4:18 PM
> To: openembedded-devel@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@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@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>