[meta-freescale] BSP Packagegroup

[Daiane Angolini]

On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <Ann.Thornton at freescale.com> wrote:
>
> For packagegroup divisions, how about
> graphics
> multimedia
> networking
> tools
> (probably others I haven't thought of)

When we think about a set of packagegroups intended to give users a
set of useful packages or an example on how to group applications more
is more. As much as possible is good enough. (meta-fsl-demos)

However, when you think about a BSP packagegroup, less is more. As
less as possible, as much closer to only critical packages, the
minimal set, is the optimal packagegroup. (meta-fsl-arm)

Do we need BSP packagegroups?

In case we do, I cannot see the need of a BSP packagegroup for graphic
(GPU) or tools.

I would accept "tools" to be split into other sets like "audio", but
definitively not "tools".

In fact, I can only see the need of a VPU and a CAN package groups.
Maybe audio. But I'm trying to stress the BSP packagegroup idea here,
something I'm not completely convinced of.


Daiane
>
> 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: Ann.Thornton at freescale.com
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>