multibuild.eclass does not have any code requiring any particular EAPI, so the whole EAPI check should be deleted: -case "${EAPI:-0}" in - 0|1|2|3|4) - die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}" - ;; - 5) - ;; - *) - die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" - ;; -esac
Sounds reasonable. Did you check it thoroughly? And what's the use case?
Eclass was fully checked.
Please reopen if you have a use case for not using EAPI=5. Removing EAPI check completely isn't future-proof.
Example use case: A system package, which needs older EAPI to preserve upgrade path.
I'm asking about real case, not theoretical one. And I exactly know what you're trying to do. Also, we're requiring EAPI=5 for current profiles. The 'upgrade path' argument is no longer useful.
Another use case, definitely real: Ebuild, which uses a newer EAPI than EAPI="5". There are currently 2 such EAPIs. EAPI of profile is unrelated to EAPI of ebuild.
There are no officially approved EAPIs 'newer' than EAPI=5.
There is no reason to force any particular EAPI in an eclass, which works with all EAPIs. Eclasses like autotools.eclass or toolchain-funcs.eclass do not have such useless EAPI checks.
(In reply to comment #8) > There is no reason to force any particular EAPI in an eclass, which works > with all EAPIs. Eclasses like autotools.eclass or toolchain-funcs.eclass do > not have such useless EAPI checks. How can I know that it works with them? A 'future' EAPI can be almost anything, and looking at the late events, they are actually a pile of random stuff.
