Summary: | repoman: missing eclass/ dir results in confusing error message | ||
---|---|---|---|
Product: | Portage Development | Reporter: | SpanKY <vapier> |
Component: | Repoman | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 358927 |
Description
SpanKY
![]() Doesn't it produce a die message from ebuild.sh? It's supposed to do something like this: * ERROR: net-misc/openntpd-3.9_p1-r1 failed (depend phase): * foo.eclass could not be found by inherit() * * Call stack: * ebuild.sh, line 1998: Called source '/usr/local/portage/net-misc/openntpd/openntpd-3.9_p1-r1.ebuild' * openntpd-3.9_p1-r1.ebuild, line 5: Called inherit 'foo' * ebuild.sh, line 1379: Called die * The specific snippet of code: * [ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()" * * If you need support, post the output of 'emerge --info =net-misc/openntpd-3.9_p1-r1', * the complete build log and the output of 'emerge -pqv =net-misc/openntpd-3.9_p1-r1'. * This ebuild is from an overlay: '/usr/local/portage/' * S: '/var/tmp/portage/net-misc/openntpd-3.9_p1-r1/work/openntpd-3.9_p1' !!! getFetchMap(): aux_get() error reading net-misc/openntpd-3.9_p1-r1; aborting. Unable to generate manifest. Anyway, if necessary I guess we can probe the ebuild for an inherit call, and use that to know about missing eclasses that are inherited directly (though it's complex if inherits are conditional, not to mention indirect inherits). Oh, now I see why you didn't get a die message. There's a portdbapi._have_root_eclass_dir variable that makes it skip execution of the ebuild if the eclass dir is missing. We can add an informative message there, and maybe tweak the logic some. This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=dee9b51ee32e9d49794f737d6e3d014ec8a3d683 This is fixed in 2.1.9.43 and 2.2.0_alpha27. |