When #646 and #645 are done, we can try to replace portage-stable with a snapshot of Gentoo.

For this to happen, we would need to add an option to our build process, that would tell it what to use - the Gentoo snapshot or the portage-stable repo. With this done, we can try running the builds with Gentoo snapshot and start fixing issues.

When build with a Gentoo snapshot produces working SDK and images, next thing would be to automate the update of the snapshot. The plan would be to have the automation to create a PR with changes taken from Gentoo every week. The PR would be a draft - it's not intended to be merged, but only to see what interesting has changed. The immediate problem here is that updating the snapshot will bring in a lot of unrelated changes, so these need to be filtered out from the PR. Having a different way of updating the snapshot than through the github PR is to keep the Gentoo snapshot a plain fork with no divergences other than being outdated for at most a week.

The automation should:

• Update the snapshot and find out what has changed between the old and new snapshots.
• Run the SDK + images build
• Find out which packages were built
  • That way we can tell that these packages are the interesting bits.
• Do an intersection of a set of updated packages with a set of built packages.
  • Tricky part - how to tell which eclasses are interesting to us? Maybe we will need some help from portage.
• File a draft PR with interesting bits.
• After getting some magic ok command, merge the new snapshot.

This is a part of #96.