Conan needs one recipe for one package.
KDE Frameworks and git repositories in general can contain multiple separately-packaged libraries.
General breakdown, a Framework could have something like:
libraries. We want those to result in separate conan packages. e.g. the "kconfig" git repository / KDE framework should result in packages for "KF5ConfigCore" and "KF5ConfigGui" (the two separate libraries that are possible).
Many distributions already break up our packages (for good reason) and this would also support efforts with Kirigami and mobile in general, in support of our goals.
Conan is able to package Boost which has many different submodules (e.g. boost_accumulators), so the technique employed here may be helpful.
With extra support in our own CMake modules to split out the libraries into separate Components (so that we could avoid confusion in CMake with trying to install all other libraries when we're just trying to install one)
We'd want to generate these recipes from a template, driven by the metadata that already exists. Otherwise we now have yet another source of dependency metadata that needs to be maintained.
But as part, we'd want to move the dependency metadata to the per-repo YAML files to replace kde-built-metadata as authoritative. Could then generate an all-in-one file for CI/kdesrc-build.
KAuth (Tier 2) depends on KCoreAddons (Tier 1)
This should be the job of a distribution, but given we general idea is to move toward a kind of SDK, then CMake/Conan becomes a distribution. This is unfortunate, but is an increasingly unavoidable issue. For the CI, we built such complete information. Why? Because the CI is in a way a distribution too.
To generate AppImages, we also need this information. We also need for generating Android APKs. In those 3 case, there is no proper Linux distribution involved. There is unsustainable duplication of this metadata across these different platforms. On top of *that*, most distributions split even frameworks into smaller packages such as `kconfigcore` and `kconfiggui`.
Adding Conan on top of this existing duplication would involve another row of duplication with a different granularity.
Even in the frameworks, this information is partially available in different places. There is the YAML file used by the doc, then `find_package` on the KF5 namespace and `find_package` for individual frameworks. Add to that we should also put this information in the config.cmake.in file to avoid dependencies warn they indirectly require a package they don't know and we have 4 places storing part of the information (or it's fully missing).