| Summary: | java-utils-2.eclass depends directly on portage | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Julian Ospald <hasufell> |
| Component: | Eclasses | Assignee: | Java team <java> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | QA | ||
| Priority: | Low | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
*** This bug has been marked as a duplicate of bug 464608 *** |
from the eclass: > has "${EAPI}" 0 1 && JAVA_PKG_PORTAGE_DEP=">=sys-apps/portage-2.1.2.7 This looks like a minor QA issue. Unless a package uses some sort of tools or API from portage, it should never depend directly on it. If the eclass depends on portage specific behavior, then it doesn't adhere to PMS. So in either case there should be a better way to handle this. I see two possibilities: * since this only affects EAPI 0 and 1 we can probably start deprecating these for the eclass * enhance the virtual/package-manager package in some way and depend on that instead