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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
