Eclasses ban old EAPIs from time to time and currently there is no way to announce the removal (except for mails to -dev). An eclass should be able to introduce vars called DEPRECATED_EAPI and BANNED_EAPI. example.eclass sets: DEPRECATED_EAPI="4" BANNED_EAPI="1 2 3" example-A.ebuild: EAPI=1 Result: repoman will prompt an error and refuse to add the ebuild to the VCS. example-B.ebuild: EAPI=4 Result: repoman will prompt a deprecation warning, ebuild can be added to VCS.
+1, this could be set up so that we can move deprecation/banning checks from eclass code to portage, i.e. portage checks EAPI, if EAPI in banned it prints a standard bailout message.
These environmental variables are rather wrong idea since ebuild can inherit multiple eclasses and different eclasses can set environmental variables to different values. A special, parsed marker in comment would be better. (Anyway die() in global scope is more effective for banned EAPIs.)
So better proposal would be # @DEPRECATED_EAPI 4 # @BANNED_EAPI 1 2 3 as already used for @DEAD?
I like comment #3, and it should produce a warning or not allow you to commit anything that is not at the current EAPI level. That way people are forced to update to current EAPI anytime they commit anything. Though that might cause issues for stablization keywording.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
I'm not sure if pkgcheck actually does this right now.
This is done at two stages: 1. banned EAPI is put as such using the eclass EAPI guard, resulting in `die` in global scope, which results in pkgcheck failing hard and blocking it. If pushed to master (without checking), this breaks the repository and notifies the dev. 2. deprecated EAPI is marked as such in repo level, and is reported by pkgcheck as warning.
