Gentoo Archives: gentoo-dev

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms
Date: Tue, 14 Oct 2008 07:48:54
Message-Id: 1223970507.18595.7.camel@sapc154.salomon.at
In Reply to: Re: [gentoo-dev] Re: [RFC] New keywords for non-Gentoo Linux platforms by Fabian Groffen
1 On Mon, 2008-10-13 at 19:59 +0200, Fabian Groffen wrote:
2 > On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
3 > > On Mon, 13 Oct 2008 06:16:01 +0100
4 > > Steve Long <slong@××××××××××××××××××.uk> wrote:
5 > > > Unless someone can say what using PROPERTIES=prefix would break, I'd
6 > > > go with that. It's a /classic/ usage of that variable, as it's simply
7 > > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
8 > > > support it. It'd be great to see the prefix branch finally merged so
9 > > > we all get to play with it.
10 > >
11 > > It would break. Prefix ebuilds won't work unless ED is set, and a non
12 > > PROPERTIES aware or non-prefix-property aware package manager won't set
13 > > ED. Unless prefix is reimplemented to require no package manager
14 > > changes for the install to / case, PROPERTIES is out.
15 >
16 > Just to comment on this possibility; I see an option, given the
17 > definition of ED and EROOT to do Prefix without them, by e.g. using
18 > ${D}${EPREFIX} instead of ${ED} as shorthand. When ${EPREFIX} would be
19 > unset, this would result in simple ${D}, which is "backwards
20 > compatible". This is not all what is necessary, but a big deal of it.
21 >
22 > Question here, however, is whether this is worth it. Personally, I
23 > prefer the shorthands, as they give a lot of readability.
24
25 Could it also work to initialize them in profile.bashrc if they are
26 unset?
27
28 Something like
29 : ${EPREFIX=}
30 : ${ED=${D}}
31 : ${EROOT=${ROOT}}
32
33 /haubi/
34 --
35 Michael Haubenwallner
36 Gentoo on a different level

Replies

Subject Author
[gentoo-dev] Re: Re: [RFC] New keywords for non-Gentoo Linux platforms Steve Long <slong@××××××××××××××××××.uk>