DeprecatedEclassReport: distinguish indirect inherits, and provide eclass-oriented report

[mgorny]

So here's a cool idea. Instead of reporting deprecated eclasses that were inherited indirectly (which has little sense given you need to fix the eclass inheriting them rather than the ebuild), let's distinguish between direct and indirect inherits, and report only the former.

Extra points if we can use the latter to produce a global 'eclass inherits deprecated eclass' report.

[radhermit]

I changed DeprecatedEclassReport about 6 months ago to only check direct inherits in c5712d8f4394447d9a92b67f8cd8be51b5d5fba6 and the commit after it.

[mgorny]

That's cool. Now it remains to have a report for eclass-to-eclass inherits.

[radhermit]

Wouldn't that be better done by parsing/regex-ing the eclasses directly? Otherwise it seems a bunch of old eclass inherits could be missed by conditional EAPI support for banned/deprecated EAPIs whose consuming pkgs have been dropped from the tree.

[mgorny]

I suppose it depends on how we define the expected result. Do we want to be bothered by indirect includes in old EAPIs that we can't remove because ebuilds are still using old EAPIs?