1 |
On Wed, 14 Sep 2011 17:32:37 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> On Thu, Sep 15, 2011 at 12:15:59AM +0100, Ciaran McCreesh wrote: |
5 |
> > On Wed, 14 Sep 2011 11:19:35 -0400 |
6 |
> > Mike Frysinger <vapier@g.o> wrote: |
7 |
> > > however, why wont this work sanely in src_* or pkg_* funcs ? the |
8 |
> > > env there is the one constructed by the PM which includes the |
9 |
> > > merged IUSE values. |
10 |
> > |
11 |
> > It's not. We deliberately don't specify that the PM passes fixed up |
12 |
> > values for IUSE, DEPEND etc back into the ebuild, since Portage's |
13 |
> > behaviour for global variables has varied considerably over the |
14 |
> > years. |
15 |
> |
16 |
> That's not varied; the implementation for eclass/ebuild stacking has |
17 |
> been pretty consistant for phase funcs. |
18 |
> |
19 |
> Either way, candidate for eapi5 if it's worth ensuring it's |
20 |
> accessible to the phases... |
21 |
|
22 |
Is that actually useful? Isn't that just a waste of time serializing |
23 |
all that data back, of which most isn't suitable for non-specialized |
24 |
parsing? |
25 |
|
26 |
If we really need to access ${IUSE}, I think we should go for something |
27 |
IUSE-specific. |
28 |
|
29 |
-- |
30 |
Best regards, |
31 |
Michał Górny |