Tools (repoman, pkgcheck) can report as QA warnings direct usage of eclasses that should never be used directly in ebuilds. I know only one eclass that is intended to be used only by other eclasses: "java-utils-2.eclass", but there are probably more of them. https://wiki.gentoo.org/wiki/Gentoo_Java_Packing_Policy#Java_specific_Eclasses This feature seems trivial to implement. @INTERNAL is likely to be mutually exclusive with @PROVIDES.
Couldn't this be checked by the eclass itself, e.g. by testing the INHERITED variable?
(In reply to Ulrich Müller from comment #1) > Couldn't this be checked by the eclass itself, e.g. by testing the INHERITED > variable? Like this? if has ${ECLASS} ${INHERITED}; then eqawarn "${ECLASS} should not be inherited directly" fi
(In reply to jan Anja from comment #2) > (In reply to Ulrich Müller from comment #1) > > Couldn't this be checked by the eclass itself, e.g. by testing the INHERITED > > variable? > > Like this? > > if has ${ECLASS} ${INHERITED}; then > eqawarn "${ECLASS} should not be inherited directly" > fi Similar to that, but instead of ${ECLASS} it would test for the allowed parent eclass. For example, java-utils-2 would test for "has java-pkg-2 ${INHERITED}" etc. I think this won't work in global scope though, so maybe it's not such a good idea.
(In reply to Ulrich Müller from comment #3) > Similar to that, but instead of ${ECLASS} it would test for the allowed > parent eclass. For example, java-utils-2 would test for "has java-pkg-2 > ${INHERITED}" etc. It's not scalable - what if java-pkg-something-else.eclass in overlay inherits java-utils-2? By the way, I found another eclass that can be marked @INTERNAL: ruby-utils
(In reply to Ulrich Müller from comment #1) > Couldn't this be checked by the eclass itself, e.g. by testing the INHERITED > variable? I think eclassdoc solution is better, as no code would run and users wouldn't see any QA warnings.
