1 |
On Wed, 19 Sep 2012 22:31:34 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Wed, 19 Sep 2012 23:24:29 +0200 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> > On Wed, 19 Sep 2012 22:14:18 +0100 |
7 |
> > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
8 |
> > > On Wed, 19 Sep 2012 23:03:05 +0200 |
9 |
> > > Michał Górny <mgorny@g.o> wrote: |
10 |
> > > > > No, you're not guaranteed to get the ebuild's value of IUSE, |
11 |
> > > > > or any particular eclass's value of IUSE, or the merged value |
12 |
> > > > > of IUSE. In particular for this case, it's possible to get |
13 |
> > > > > false negatives. |
14 |
> > > > |
15 |
> > > > Then fix the spec. |
16 |
> > > |
17 |
> > > The spec accurately reflects the mess that is global and metadata |
18 |
> > > variables. Portage has historically done all kinds of different |
19 |
> > > things here (sometimes varying depending upon whether you're a |
20 |
> > > binary, whether things are being loaded from VDB, whether env |
21 |
> > > saving has happened previously etc), and the code is rather |
22 |
> > > sensitive to apparently minor changes in bash versions. Thus we |
23 |
> > > don't provide guarantees. |
24 |
> > |
25 |
> > The historical mess is not relevant anymore. Is there a single real |
26 |
> > case when IUSE does not contain *at least* the ebuild-set IUSE? |
27 |
> |
28 |
> The historical mess applies to things under EAPI control. If you want |
29 |
> stronger guarantees, you know how to propose things for a future EAPI. |
30 |
|
31 |
You didn't answer my question. |
32 |
|
33 |
-- |
34 |
Best regards, |
35 |
Michał Górny |