The information we compute is a good starting place for what should go in the desktop-runtime and fedora-runtime modulemd.

desktop-runtime - components should include all the srpms for the rpms that are part of the fedora-runtime/runtime profile that aren't "legitimately" inherited from another module (platform or X11-base is legitimate, installer is not)
fedora-runtime - should have profiles for runtime/runtime-base/sdk/sdk-base based on the package lists we compute. components should include any srpms that are needed in the sdk or sdk-base profile that we don't inherit from desktop-runtime or another module.

We probably want to consider updating the modulemd files to be a manual operation rather than an automated "generation" step - we don't want to accidentally introduce a bunch of stray packages just because a new file accidentally leaks into the GNOME or Freedesktop runtime.

Different approaches:

• generate "candidate" modulemd files as an output of 'make', let the maintainer copy them into the git repositories for the modules, diff, commit if appropriate. This requires templating or some other way to handle parts of the modulemd files that in hand-written (description, buildroot profile, etc.)
• use the old modulemd files as input to report generation and highlight things that need to be added or removed.
• Hybrid: use the old modulemd files as templates to generate new modulemd files.