>>>>> On Tue, 15 Dec 2009, Fabian Groffen wrote: > With the current route where EAPI=3 will simply be EAPI=2 + > offset-prefix support,
That's not entirely right, as EAPI 3 will also include mtime preservation. > Should an ebuild using an EAPI that has offset-prefix support make the > use of that support mandatory or optional? 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? I'd say you can only claim Prefix support for an ebuild, when that ebuild has been tested under Prefix, i.e. when KEYWORDS contain at least one Prefix architecture. > 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 Again, we have KEYWORDS for this. > - hence also obviously is (supposed to be) checked for Prefix I don't see this as a pro. At least I don't want to delay any updates to EAPI 3 (which I need for mtime preservation), only to ensure that the ebuild is also working in Prefix. Most of my ebuilds in question aren't even in the Prefix overlay. Also there are some packages that are Linux-only and will never run on Prefix. Certainly we don't want to restrict them to EAPI <= 2 forever? Ulrich
