Currently it appears portage only outputs QA warnings (via the _check_build_log() function) before a pkg is merged for unknown commands encountered while running ebuild phases. This feels optimistic at best that someone will notice and fix such warnings.
One example would be the current version of guile-2.2.6 in the tree that uses the filter-flags function in src_configure() but doesn't inherit the flag-o-matic eclass anymore where the function is defined. It appears the eclass was properly inherited in 2.2.4, but was possibly removed from 2.2.6 after deeming it unnecessary since no failures occurred and/or the build log wasn't examined after a successful build.
There have been and mostly likely still are many other examples of this throughout the tree. I know because pkgcore calls die when it encounters this situation and I think portage should do the same.
In summary, I think portage should define the command_not_found_handle() hook that calls die with a relevant message for all ebuild phases forcing developers to fix this issue in their ebuilds and eclasses.
For more inspiration, here is how pkgcore handles things: https://github.com/pkgcore/pkgcore/blob/master/ebd/ebuild.bash#L332
Let's make it fatal for EAPI 8.
(In reply to Zac Medico from comment #2)
> Let's make it fatal for EAPI 8.
Is this in EAPI 8?
Note that this is more of a pain for src_test where often there are false positives.
No, it has not been proposed for EAPI 8. However, I think it is still fine to add it at this point. Not that anyone has time to push more of EAPI 8 forward.
I presume this is just about commands directly called by ebuild and not by external tools/scripts.
Would this only catch commands called directly from a phase function, or also commands executed from within the package's build system?
For the latter, I've seen several false positives, so I'm sceptical if catching this would be feasible.
(In reply to Ulrich Müller from comment #5)
> Would this only catch commands called directly from a phase function
Yes. command_not_found_handle() function here is not exported.
> or also commands executed from within the package's build system?
No. Such behavior would require additional 'export -f command_not_found_handle'.