For many DEY releases, we've been providing one SDK per image type, per
platform. In the case of graphical images, this was redundant for a few
reasons:
* Most of the SDK's contents were identical, save for the specific packages
in each image (qt, webkit, lvgl...) and their dependencies. With each SDK
occupying over 1.5 GiB, this results in a lot of storage space overhead
in our servers.
* For some images, namely webkit and lvgl images, their respective SDK
packages aren't necessary for the expected development use cases, so it's
perfectly possible to use the qt SDK instead.
Create a separate recipe for a general-use SDK. Said toolchain includes qt5/qt6
packages by default, except for headless platforms. The advantages of this are:
* We only provide one prebuilt SDK per platform, all with the same base
name. The SDK should cover most if not all of the expected development
use cases, and customers are still able to create their own custom SDKs
if needed.
* Having a separate recipe for the toolchain, not tied to a specific image
type, allows us to fine tune its contents without affecting images and
their recipes. With time, we can incorporate new packages as needed.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
7f6898e1c6