Future EAPI/EAPI 5 tentative features

This is a working page that contains references to all features that have been suggested for EAPI 5.

Features where a wording of the spec and a Portage implementation are ready

 * Slot operator dependencies
 * PMS wording, Portage patch


 * Sub-slots
 * PMS wording, Portage patch


 * Profile IUSE injection
 * PMS wording, Portage patch


 * econf --disable-silent-rules
 * PMS wording, Portage patch


 * At-most-one-of operator for REQUIRED_USE
 * PMS wording, Portage patch


 * EBUILD_PHASE_FUNC variable
 * PMS wording, Portage patch


 * Mandate GNU find
 * PMS wording , no Portage patch needed


 * new* commands can read from standard input
 * PMS wording, Portage patch


 * Parsing of the EAPI assignment is mandatory
 * PMS wording, Portage patch


 * src_test support for parallel tests
 * PMS wording, Portage patch


 * Stable use forcing and masking
 * PMS wording, Portage patch


 * Option --host-root for {has,best}_version
 * PMS wording, Portage patch


 * doheader helper function
 * PMS wording, Portage patch


 * usex helper function
 * PMS wording, Portage patch

Things where additional discussion may be needed

 * econf --disable-silent-rules (see above)
 * Apply retroactively to EAPI 4?
 * Apply retroactively to all EAPIs? (May be problematic because of additional configure call.)


 * User patches
 * PMS wording, Portage no-op dummy stub
 * Intrusive.
 * Current wording of the spec requires that every ebuild includes a call to the apply_user_patches function in src_prepare. An alternative would be to apply user patches after src_prepare as a default, if the ebuild doesn't call the respective function.
 * The spec doesn't provide any kind of epatch function, so we will end up having two copies of epatch, one for user patches, and the other (from eclass) for ebuilds.
 * Are we happy with the name apply_user_patches? (epatch_user? euserpatch?)


 * License groups in ebuilds
 * A simpler solution would be create separate license files like GPL-2+ for the few cases where this is needed. This would have the advantage that it could be applied to all EAPIs.
 * A simpler solution would be create separate license files like GPL-2+ for the few cases where this is needed. This would have the advantage that it could be applied to all EAPIs.


 * EJOBS variable
 * 
 * Discussion was almost 4 years ago. Is there (still) consensus?


 * Source eclasses only once
 * 
 * 


 * Extended default list of extensions in dohtml
 * Objections against inclusion of non-standard extensions like .ico have been raised.
 * Objections against inclusion of non-standard extensions like .ico have been raised.


 * REPOSITORY variable
 * Controversial, see bug.
 * Controversial, see bug.


 * Repository dependencies
 * Controversial, see bug.
 * Controversial, see bug.

Not sure if the following are candidates for EAPI 5

 * Cross-compile support
 * 


 * package.mask, use.force, use.mask, package.use, package.use.force and package.use.mask directories
 * Need profiles EAPI bump
 * Need profiles EAPI bump


 * make.defaults, use.force, use.mask, package.use, package.use.force and package.use.mask in ${repository_path}/profiles
 * Need profiles EAPI bump
 * Need profiles EAPI bump


 * HDEPEND: host dependencies for cross-compilation