This epic is for tracking all issues related to making all ebuilds on a Funtoo stage3 fully "Funtoo-ized". Before I go into specifics, this is an opportunity to make ebuilds really elegant, clean and maintainable and allows us to get them into a nice YAML-based framework for future maintenance. So this is a really neat project for those who want to make ebuilds better and what they really should be, like little works of art.

Specifics:

1. Ebuilds should be streamlined to make them as clean, straightforward, elegant and maintainable as possible.
2. Autogen should be used – even if we may not want to use the most recent version. We will eventually want to be able to control the version used from YAML.
3. For core toolchain ebuilds, we would like the ability to build them in a simpler, non-slotted way as an option, as well as slotted (for example, I am doing this for binutils.) This helps us when we want to bootstrap Funtoo from a non-Funtoo/Gentoo or even non-Linux OS.
4. High-quality comments to describe what we are doing in the ebuild and why, when it is not obvious.
5. If possible, remove dependence on eclasses in favor of metatools-based solutions.

I am going to make separate issues for each catpkg that needs to be Funtoo-ized so we can track work on each catpkg individually.

FAQ

1. Do I need to remove all the eclasses from the ebuilds? Answer: No, you do not need to remove all of them. Just remove some if it is convenient, as an overall process of simplifying the build process of the ebuilds. We are trying to get the ebuilds to be simpler and more maintainable. This will be an ongoing process. We are just trying to get things to as good a place as we can in a reasonable timeframe right now. Don't go crazy removing eclasses right now, but if you see the opportunity then go for it.
2.  How do I hard-code the version when I am writing an autogen.py? If you are using an individual autogen, allow a version to be specified in a variable in the python code itself as a temporary hack, but then check upstream to see if the version is actually available. You should also recognize the special version string "latest" to mean "built the latest upstream version available". When you write your autogen.py, you can simply set version = "x.y.z" in the autogen.py. It should make sure this version actually exists upstream, and build for this version. This hard-coding of the version number will eventually be removed as we move versions over to an autogen.yaml file which will contain a master list of versions.
3. Which catpkgs should I focus on first? I recommend you start with the easy ones first. Things that are (in my opinion) easy are stand-alone tools and archivers, rather than libraries. Things like glibc are harder and may take a lot of time. Knocking out a bunch of easy autogens is very helpful. Just like a jigsaw puzzle, it can be helpful to get the easy catpkgs in place first.
4. What about dependencies of these catpkgs? Deps of the listed catpkgs are also fair game for autogen and funtoo-ization. I would like to create an issue for each catpkg we're converting. Just ping me on discord and I'll create an issue for any deps you want to funtoo-ize and you can start working on them.