On 09-10-2008 19:15:26 +0100, Ciaran McCreesh wrote: > On Thu, 9 Oct 2008 19:46:55 +0200 > Fabian Groffen <[EMAIL PROTECTED]> wrote: > > Currently in Prefix we implemented EAPI as being a set of tokens that > > are orthogonal to each other. In other words, while 0, 1 and 2 are > > mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result > > is something like EAPI="prefix 1". Of course with this approach the > > recent introduction of EAPI=2, resulted in a problem with eclasses > > that do a blind check on the EAPI variable to be e.g. 2. > > EAPI's defined as being a single value because mixing between EAPIs is > in general impossible. For example, I'm guessing prefix might need to > do something to econf / the default src_compile/configure functions at > some point, so it's not really truly independent.
While that is true, currently Prefix is designed in such a way that an empty offset results in a fully "backwards" compatible Portage. > Is there anything stopping you from formalising your specification of > what you need? (The PMS team can probably help with the 'writing formal' > bit if necessary, given an informal description.) Could it be done in > such a way that non-prefix package managers can do minimal support to > get the current /usr behaviour, whilst optionally implementing > everything else? If this is the case, the best route's probably to get > the whole thing into the next EAPI, start using that EAPI for all your > overlay packages and persuade people to include the necessary prefixy > things in main-tree eclasses (which they should, once said EAPI is > Council approved). A problem I have with requiring a "next" EAPI for each ebuild, is that Prefix requires all base-system ebuilds to be "Prefix compatible". However, this category of ebuilds requires being conservative with EAPI requirements. I once started on an attempt to document the stuff[1], but it's pretty verbose, and it misses the necessary informal definitions of in particular chapter [2]. > > Something that was raised in previous discussions was that maybe the > > Prefix extensions don't need an EAPI in itself, but that an ebuild has > > to be marked as Prefix-ready through e.g. the recently proposed > > PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be > > added variable. > > What's the scope of the changes? I think it'd be easiest to discuss > this if you posted an informal summary describing the differences in > terms of which bits of PMS are affected. [2] sums it up for as much as I can recall for the moment, the non-privileged stuff is supposed to be separate, but its use is inherently related to offset installations. Our overlay[3] contains enough material to get an idea of what it looks like in practise. If you want specific pointers, I can give you them. [1] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html [2] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html#ebuild-changes-in-prefix [3] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay -- Fabian Groffen Gentoo on a different level
