[agl-discussions] [meta-agl] Suggestion for how to decide which packagegroup to add packages to

Streif, Rudolf rstreif at jaguarlandrover.com
Thu Sep 10 04:13:28 UTC 2015

Hi Jonathan,

Thank you for your suggestions. They make sense. A couple of annotations:

I have been thinking about an issue of which packagegroup a package
> needs to be added to, which became significant to me when I was looking
> at OS/Common Libs.
> The issue is that meta-agl has three different packagegroups related to
> the OS/Common Libs subsystem:
> ./meta-ivi-common/recipes-core/packagegroups/
> packagegroup-ivi-common-os-commonlibs.bb
> ./meta-agl/recipes-core/packagegroups/
> packagegeoup-agl-core-os-commonlibs.bb
> ./meta-agl/recipes-ivi/packagegroups/packagegroup-agl-ivi-os-commonlibs.bb
> Package groups group packages from the same package category into logical
bundles that simplify the creation of images. The package groups you find
in recipes-core/packagegroups all bundle packages that are build from
recipes within recipes-core. Unfortunately, in the OpenEmbedded Core layer
meta pretty much all of the package group names start with
packagegroup-core, which makes it hard to find where the package group is
actually defined. I think it would have been better the prefix the package
groups defined in recipes-core with packagegroup-core, the ones defined in
recipes-extended with packagegoup-extended, etc. which would help to find
their definitions when you see them listed in the IMAGE_INSTALL variable of
an image recipe.

However, for meta-agl and other AGL layers we can name the package groups
and the recipe categories whatever we would like them to be. If we add a
package group to recipes-core in the meta-agl layer I agree to prefixing it
with packageroup-agl-core then one would know to look in
meta-agl/recipes-core/packagegroups for its definition.

> After discussing this with Tanikawa-san and Walt during the AMM, the
> solution appears to be the following:
> * If the package is already included in the system via dependencies,
> then you do not need to add it to any packagegroups (e.g. gstreamer is
> in the multimedia packagegroup. If gstreamer depends on libc, libc does
> not need to be added to OS/Common Libs)

correct, in particular for the C library.

> * If the package came from Yocto (meta-ivi) or Tizen, it goes in the
> packagegroup inside meta-ivi-common.

yes, and preferable if, for instance, that recipe is put into
meta-ivi-common/recipes-xxx/yyy/yyy_v.v.bb a package group that includes it
should be in a package group that is defined in a recipe inside

> * If the package is required for the minimal image to boot, it goes in
> the packagegroup inside meta-agl/recipes-core.

The criteria for a package group to go into a particular recipe category is
that the packages it bundles are in the same category. That makes finding
stuff easier.

> * If the package is required for the full image, it goes in the
> packagegroup inside meta-agl/recipes-ivi.

See above and images that use those package groups are typically defined in
the subdirectory images. So, if there are recipes in meta-agl/recipes-ivi
then they are grouped by package groups in
meta-agl/recipes-ivi/packagegroups and those package groups are used by
images defined in meta-agl/recipes-ivi/images.

> A related issue is where to put the related .bb, .bbappend, and any
> other loose files that are going into a project. If they came from Yocto
> (meta-ivi) or Tizen, they should go into the meta-ivi-common layer.
> Otherwise, they go in meta-agl.

That sounds reasonable.

> For OS/Common Libs, they would probably be added to a subdirectory in
> meta-agl/recipes-extended       (e.g. the "foo" project may lead to the
> creation of the files meta-agl/recipes-extended/foo/foolib.bb and
> meta-agl/recipes-extended/foo/foo.service)

I do not expect too many of those. If they are not already in OECore meta
then you will probably find them in meta-openembedded and one of its
sublayers. It is always worth checking the OE layer index first before
writing a new recipe.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150909/cc6f7bec/attachment.html>

More information about the automotive-discussions mailing list