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