Summary: | eclassdoc: @INTERNAL tag for eclasses that should not be inherited in ebuilds | ||
---|---|---|---|
Product: | Quality Assurance | Reporter: | Anna Vyalkova <cyber+gentoo> |
Component: | Disputes/raising issues | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Anna Vyalkova
2022-02-09 17:53:42 UTC
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. |