While working on SPEC-4714, it struck me that there are quite a few cleanups that were deferred in the Marlin release timeframe that we really should get resolved for Pike as opposed to letting slide any further.  A lot of these stem from the focus a few year back on trying to define base profiles and images for a lot of features / usecases without any real feedback from members on whether there was/is any value add to them.  The old application framework drove some of this with respect to services being included or not, but we did also have a bit of an explosion of things for Qt, plain, HTML5 vs IVI, cluster, telematics, etc.  The intent of this work is to continue the cleanup that was done during Marlin to try to get to something more straightforward for downstream users.  If there is later a significant interest in trying to define "profiles" via Yocto somehow, we can then visit that with a clean(er) slate.

The proposed rework includes:

• Removing packagegroup-agl-profile-*, most of which are empty.  The ones that are not empty tend to include packages that do not seem likely to be used in downstream projects.
• Moving from agl-.inc include files as a base for a lot of the images to just using agl-.bb image recipes directly.  This avoids a level of indirection that for the most part provides no real benefit, and aligns us with how upstream OE/YP documents extending their core-image*bb recipes.
• Removing any image recipes that do not have a clear usecase for either demos or as the base for downstream projects.
• Trying to remove all packagegroup bbappends of remaining packagegroups as possible.  Such bbappends tend to obfuscate image construction, and are a blocker to any real attempt to usefully demonstrate setting up a binary packagefeed.
• Removing packagegroup-hmi-framework, as it is an artifact from the old application framework.
• Investigate removing the packagegroup-agl-ivi-* recipes in meta-agl-demo, as they are for the most part very specific to our demos and likely not useful for downstream.  If they are kept with an eye to enabling downstream demo construction / modification, then renaming them to something more evocative of demo usage should be considered.
• Reworking remaining packagegroups to be standalone groups of packages without explicit dependencies on image content packagegroups (e.g. packagegroup-agl-image-minimal).  The intent is to have packagegroups be well-defined sets of related packages that can potentially be more easily reused in image recipes without tying them to some concept of stacking on top of a particular profile/image hierarchy.  This is also more along the lines of how packagegroups are used in upstream poky.

It is possible that sub-tasks may be opened for some of the above as opposed to doing all the work under this issue directly.