On Thu, Jul 9, 2015 at 1:29 PM, Ann Thornton <[email protected]> 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: [email protected] > > -- > _______________________________________________ > meta-freescale mailing list > [email protected] > https://lists.yoctoproject.org/listinfo/meta-freescale > -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
