On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <pa...@gentoo.org> wrote: > El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 20/09/12 09:52 AM, Ciaran McCreesh wrote: >> > On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius >> > <a...@gentoo.org> wrote: >> >> PMS may not need to be fixed, just the spec >> > >> > PMS is the spec, and it doesn't need fixing, since it accurately >> > reflects the situation we're dealing with. >> > >> >> Sorry, I misread PMS as PMs (portage, paludis, etc). >> >> And, for support to be official for ebuilds or eclasses to query IUSE >> (or other globals) within phase functions, then the 'spec' (PMS) is >> probably all that needs to be 'fixed'. Right? >> >> So, in EAPI=6, we propose something that'll make it official (ie a >> querying function; or ensure that PMs can provide these variables >> along with their proper 'effective' values, or their in-ebuild >> 'explicit' values, or whatever it is we want to say can be relied >> upon, to the environment). >> > > The problem of waiting for eapi6 to specify CURRENT behavior is that we > don't know how much time will need to wait until it's approved (as I > think eapi5 cannot include this "extra" function as was approved some > hours ago). Other option would be to fast release some kind of eapi5.1 > adding this... but, again, I think we are discussing about something > that could be resolved as simply as specifying current behavior for all > existing eapis (as we are in fact doing in the tree) and rely on new > eapis for future hypothetical changes on it.
The key question is: How would you formally describe the current behavior? I think someone already noted it's not reliable behavior in all places. -- :wq
