On 09-10-2008 19:15:26 +0100, Ciaran McCreesh wrote:
> On Thu, 9 Oct 2008 19:46:55 +0200
> Fabian Groffen <grobian@g.o> 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
|
