On Wed, 19 Sep 2012 22:31:34 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Wed, 19 Sep 2012 23:24:29 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > On Wed, 19 Sep 2012 22:14:18 +0100 > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Wed, 19 Sep 2012 23:03:05 +0200 > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > No, you're not guaranteed to get the ebuild's value of IUSE, > > > > > or any particular eclass's value of IUSE, or the merged value > > > > > of IUSE. In particular for this case, it's possible to get > > > > > false negatives. > > > > > > > > Then fix the spec. > > > > > > The spec accurately reflects the mess that is global and metadata > > > variables. Portage has historically done all kinds of different > > > things here (sometimes varying depending upon whether you're a > > > binary, whether things are being loaded from VDB, whether env > > > saving has happened previously etc), and the code is rather > > > sensitive to apparently minor changes in bash versions. Thus we > > > don't provide guarantees. > > > > The historical mess is not relevant anymore. Is there a single real > > case when IUSE does not contain *at least* the ebuild-set IUSE? > > The historical mess applies to things under EAPI control. If you want > stronger guarantees, you know how to propose things for a future EAPI. You didn't answer my question. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
