| 1 |
El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA256 |
| 4 |
> |
| 5 |
> On 20/09/12 09:52 AM, Ciaran McCreesh wrote: |
| 6 |
> > On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius |
| 7 |
> > <axs@g.o> wrote: |
| 8 |
> >> PMS may not need to be fixed, just the spec |
| 9 |
> > |
| 10 |
> > PMS is the spec, and it doesn't need fixing, since it accurately |
| 11 |
> > reflects the situation we're dealing with. |
| 12 |
> > |
| 13 |
> |
| 14 |
> Sorry, I misread PMS as PMs (portage, paludis, etc). |
| 15 |
> |
| 16 |
> And, for support to be official for ebuilds or eclasses to query IUSE |
| 17 |
> (or other globals) within phase functions, then the 'spec' (PMS) is |
| 18 |
> probably all that needs to be 'fixed'. Right? |
| 19 |
> |
| 20 |
> So, in EAPI=6, we propose something that'll make it official (ie a |
| 21 |
> querying function; or ensure that PMs can provide these variables |
| 22 |
> along with their proper 'effective' values, or their in-ebuild |
| 23 |
> 'explicit' values, or whatever it is we want to say can be relied |
| 24 |
> upon, to the environment). |
| 25 |
> |
| 26 |
|
| 27 |
The problem of waiting for eapi6 to specify CURRENT behavior is that we |
| 28 |
don't know how much time will need to wait until it's approved (as I |
| 29 |
think eapi5 cannot include this "extra" function as was approved some |
| 30 |
hours ago). Other option would be to fast release some kind of eapi5.1 |
| 31 |
adding this... but, again, I think we are discussing about something |
| 32 |
that could be resolved as simply as specifying current behavior for all |
| 33 |
existing eapis (as we are in fact doing in the tree) and rely on new |
| 34 |
eapis for future hypothetical changes on it. |
Archives