The SDK consists of three parts:
(1) The host part (compiler and other tools)
(2) The target part (libs and headers)
(3) Other misc files added at the end (environment setup script, etc.)

Currently, we use the package manager to assemble parts 1 and 2, but not because a package manager is necessarily required - unlike with images the package manager is not used within the SDK itself. We'd like to be able to easily extend/update the SDK after installation, and using the package manager may seem like the logical next step. However, if we take earlier efforts to manage the sysroot in OE as a lesson, where we tried twice to use a package manager without much success and in the end ended up with sstate, the package manager often gets in the way for this kind of thing e.g. by imposing versioning. We have the files written out from the do_populate_sysroot / do_package tasks as they were most recently written out in the form of sstate archives; we can simply extract those to form the SDK.

We can then create a list of the components used to assemble these parts along with their signatures, and place this within the SDK along with the individual sstate manifests (lists of files per component) for use during update.