With the current route where EAPI=3 will simply be EAPI=2 + offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the following question arose:
Should an ebuild using an EAPI that has offset-prefix support make the use of that support mandatory or optional? In other words, one can perfectly fine write an ebuild EAPI=3 that will not work in an offset-prefix install, due to improper absence of EPREFIX, ED and EROOT. Should we allow this formally, or not? Why is this a problem? Simply because it can be done, but more because EAPI=4 will introduce features a developer would like to use/rely on, while she/he does not want, or is not able to write the ebuild in a Prefix conforming way. The pros for forcing ebuilds to be offset-prefix aware are: - an ebuild having EAPI >= 3 (as it looks now) is supposed to work for Prefix users - hence also obviously is (supposed to be) checked for Prefix - repoman might be able to check for obvious mistakes regarding offset-prefix installations The cons: - all developers need to be aware of how Prefix works, and be able to write ebuilds for it (I can post all the answers to the Prefix quiz) - basically requires a Prefix to be setup to test - it will stop developers to some degree to use higher EAPIs in the worst case The pros for allowing ebuilds that have an offset-prefix aware EAPI to ignore the offset-prefix are: - easy drop-in replacement for devs, basically the contra of all the cons of the previous approach. The cons: - not immediately clear which ebuild is offset-prefix aware (could look at Prefix keywords) - needs proper rules; an ebuild that has offset-prefix support may not have this support removed again (breaks Prefix users, how to enforce?) - ebuilds may get offset-prefix support at a later stage, which may not entirely be understood/noticed by (their maintaining) devs Please voice your opinion and share your insights, if any. -- Fabian Groffen Gentoo on a different level
