I am not sure if the place for this would be in repoman or as a QA warning shown by python eclasses. I think we should warn developers when they forget to even try to add support for newer python versions in PYTHON_COMPAT (if the package doesn't work with, for example, py3.5, the warning is still ok as that package will need to be fixed sooner or later). Currently, it's always a headache to dig into all python reverse deps to try to make them compatible with newer python versions. And this work needs to be redone on every python release, then, seeing people still committing new ebuilds without this is... :S Thanks
At least it seems people are not against this :) https://archives.gentoo.org/gentoo-dev/message/7e5e71d97310869c09f334722fea7d1d
yes, we certainly could add a repoman module to check and nag about that. I am just about done with part1 of the stage3 rewrite. It has split the line-checks into a plugin system as well. So it should be easier to create a check for that.
Parsing PYTHON_COMPAT (bash syntax) directly from the ebuild would be tricky, so we'd probably want implement this using the python_targets_* flags in IUSE.
gpyutils already relies on PYTHON_COMPAT being able to be evaluated via bash sanely (but uses USE flags as speedup). USE flags won't work for python-any-r1 ebuilds.
Maybe, if it's too hard to implement in repoman side, a check could be added to python-utils-r1.eclass. If the highest "impl" is not found in PYTHON_COMPAT it could show an eqawarn message :/
To be honest, I don't think adding it to the eclass is a good idea. Many users have QA warnings enabled, so this would be very verbose way of doing it, and it will result in a lot of bugs filed. It would become especially problematic if the newer Python version is supported in newer ~arch version but people using stable will see it nevertheless.
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.
