Right now, packages.yaml in metatools is used to list packages that are included from outside repositories, like from gentoo's main portage tree or other overlays.

However, packages.yaml is also useful for the purposes of documentation, not just as instructions on 'what catpkg to grab from where'. For this purpose, it would be useful to be able to refer to autogenerated catpkgs in packages.yaml.

For example, we are looking into adding imagemagick back to next-release (it was removed in a major beard trimming.) It has a number of dependencies, which we may want to pull from Gentoo. But it would also be great to be able to list imagemagick itself, as we want to document that this is an important catpkg. But we do plan to autogen it. So I may work on a much-enhanced packages.yaml syntax that is more than just mapping catpkg to source repo.

Here is an example of a proto-format that can be used to start to collect catpkg info and their relationships, even for autogenned ebuilds:

key_media_packages:
  defaults:
    source: gentoo-staging
  packages:
    - local:media-gfx/imagemagick 
    - virtual/imagemagick-tools
    - media/libs/foobar

Above, we are organizing catpkgs into a logical collection called key_media_packages. The last two catpkgs are sourced from gentoo-staging, but we also list imagemagick itself – the "local:" prefix indicates this package should appear in media-kit kit-fixups, as a fork or autogen. This allows us to remember that imagemagick is an important package that must be included. This allows us to use packages.yaml as potentially a complete reference for what is in a kit, including autogens.

Gradually, this functionality should allow us to collect related ebuilds into logical groups – groups that are currently dispersed throughout many categories. In the small example above, imagemagick also has a virtual. These things are easy to miss when you are maintaining a particular package, unless you are very familiar with the package in question.

Another example of this is gstreamer itself, which has tons of sibling ebuilds and they are all over media-libs as well as media-plugins. 

With this feature, we can start to build packages.yaml as living documentation of what is in a kit.

Actively seeking creating input here. Let's make this good.