Before we seriously think about implementing mix-ins in profiles, we need to think how repoman should work with them. In particular, repoman checks deps with various profiles. With mix-ins in-place, the number of possible combinations grows pretty insane...
It's not feasible for repoman to check all combinations. So, it seems like the the only practical option is to continue having repoman check a basic set of profiles defined in profiles.desc. The users of mixins will simply have to file bugs for any issues that they find. It's a fair trade-off for the flexibility that mixins provide.
Could we have a set of repoman profiles, which inherit the combinations of mix-ins that will be tested? For example, we could have a repoman-default-amd64 profile that inherits everything you need to create something similar to the default profiles. The repoman profiles could all be located in a directory or referenced in a file, and repoman would check just those profiles. You could also have different categories of profiles that get more/less checking, similar to what is done today with dev/stable/etc archs. But, that would be more generic. So, maybe amd64-selinux is dev, but amd64-default is stable, or something like that.
Yes, that is very doable. In fact the repoman rewrite will move all data that can be moved, moved out of the code into separate files that can be downloaded and/or retrieved from the tree. That will take the pressure off of needing to make new releases of repoman/portage whenever some minor change to the data it uses for the checks changes. I am finished with the stage2 rewrite other than completing the docstrings. Then I can start on the stage3 rewrite which will move the data out of the code to a central location. From there it can be decided if this data is to be downloaded similar to the repositories.xml list and/or some of that data is supplied in the tree itself. This would also make it possible for any other applications to make use of that data for running it's own checks.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
