Hi Roberto,
On Tuesday 03 November 2015 10:36:20 Roberto wrote:
> I have written the following packagegroup called packagegroup-amatek.bb for
> testing purposes :
>
> # Copyright (C) 2012-2013 Freescale Semiconductor
>
> # Released under the MIT license (see COPYING.MIT for the terms)
>
> DESCRIPTION = "Example package group"
>
> LICENSE = "MIT"
>
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
>
>
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
> PR = "r5"
>
> inherit packagegroup
>
> PROVIDES = "${PACKAGES}"
>
> PACKAGES += " \
>
> ${PN}-package1 \
>
> ${PN}-package2 \
>
> "
>
> RDEPENDS_${PN}-package1 = " \
>
> package1-depend1 \
>
> "
>
> RDEPENDS_${PN}-package2 = " \
>
> package2-depend2 \
>
> "
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
>
> If in my custom image file (amatek-image) I include only
> packagegroup-amatek-package1:
>
>
>
> IMAGE_INSTALL = "packagegroup-amatek-package1"
>
>
>
> I would expect that package2-depend2 is not installed because it is a
> dependency of the package packagegroup-amatek-package2 which is not
> installed.
>
>
>
> However, bitbake amatek-image -g -u depexp shows that package2-depend2 is
> installed as well:
>
>
>
> <http://i.stack.imgur.com/xRj1E.png> enter image description here
>
>
>
> Is this the expected behaviour?
When you say depexp shows that it's installed, how are you determining that?
For the most part, depexp shows build-time dependencies; in order to *build*
your packagegroup the dependencies for all of the packages that that
packagegroup recipe creates need to exist, which means all those dependencies
need to be built - so that explains why package2-depend2 is being built.
Image construction is under the control of the package manager, and whilst we
know most of the inputs to that process we can't account for all of the
package manager's behaviour, so the only reliable way of determining the final
contents of the image is to actually build the image and then inspect what
went into it. You can use buildhistory to get an analysis of the image contents:
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality
When enabled, buildhistory will not only write a list of the packages that went
into the image (in several formats) but will also write a .dot graph file
showing
the dependency relationships between packages in the image which you can
inspect to see why something was added.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
