For packagegroup divisions, how about
graphics
multimedia
networking
tools
(probably others I haven't thought of)

Each of those groups might be further divided into minimal, core, demos, extended as needed.

Each packagegroup could check DISTRO-FEATURES, etc so that they would be as generic as possible.

Then recipes could include the level of detail desired and they would work across product lines.

Ann Thornton

On 7/9/2015 9:56 AM, Daiane Angolini wrote:
For me, packagegroup is only a set of packages wrapped together to
make my life easier.

Should BSP provide packagegroups to ease the addition (and removal) of
set o BSP packages, or their “functional” dependency. For example an
application such as aplay is needed to stress the audio functionality,
even though there is no dependency from alsa driver from kernel with
alsa-utils. Should BSP provide packagegroups?

I think offering packagegroup options to enable BSP pieces may really
ease the BSP usage, however I main point here is how far should BSP
go. What is the limit between a BSP packagegroup and a "demo"
packagegroup (as we does in meta-fsl-demos)?

Thinking about a package group to provide BSP packages related with
VPU, in my opinion it should have:

* VPU firmware
* VPU lib

In case I’m using gstreamer, I would like a packagegroup like:

* VPU firmware
* VPU lib
* gstreamer plugins for VPU (gstreamer-imx or gst1.0-fsl-plugin)

In case I’m using gstreamer with kernel mainline:

* VPU firmware
* gstreamer


Should mp3 encoder (such as lame) be part of a BSP packagegroup? And
in GPU case? Would DEPENDS and PROVIDES be enough to include needed
packages?

Should meta-fsl-arm (or meta-freescale) provide a bluetooth BSP
packagegroup even though there is no special hardware acceleration
provided by meta-fsl-arm for bluetooth?


Daiane


--
Ann Thornton

/Microcontrollers Software and Applications
Freescale Semiconductors
email: [email protected]/
-- 
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale

Reply via email to