How to install only a subset of the packages listed in a packagegroup?

How to install only a subset of the packages listed in a packagegroup?

[Roberto]

[-- Attachment #1.1: Type: text/plain, Size: 1360 bytes --]

Hi,

 

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?

Regards,

Roberto


[-- Attachment #1.2: Type: text/html, Size: 16752 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 4537 bytes --]

Re: How to install only a subset of the packages listed in a packagegroup?

[Paul Eggleton]

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