LTO makes a lot of sense, but gives a lot of scope for how to implement it across the board. It also creates issues with breaking some packages. Therefore, a method to minimise the chances of breakage is key to the implementation.
- List of packages it's disabled on other distros (Ubuntu, Opensuse, Fedora)
- LTO thin vs full (thin seems only useful on large packages from my experience)
- Evaluate the impact on package size
- Evaluate the impact on build times
- Ensure clang/lld are tuned for this (LTO/PGO wise)
- Have an ABI map before initially making it default
- A process for validating lto is mangling/deprecating symbols in the library (nm with symbol versions)
- Determine whether having it globally, or simply enable for the important packages
LTO isn't necessarily the way to make the smallest packages. -fdata-sections and -ffunction-sections with proper GC leads to smaller file sizes, but those flags can reduce performance (less inlining, but both GCC and Clang use them, so may be favoured to reduce duplication in larger C++ software.