| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 20/09/12 02:12 PM, Michael Mol wrote: |
| 5 |
> On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <pacho@g.o> |
| 6 |
> wrote: |
| 7 |
>> El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió: |
| 8 |
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 |
| 9 |
>>> |
| 10 |
>>> On 20/09/12 09:52 AM, Ciaran McCreesh wrote: |
| 11 |
>>>> On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius |
| 12 |
>>>> <axs@g.o> wrote: |
| 13 |
>>>>> PMS may not need to be fixed, just the spec |
| 14 |
>>>> |
| 15 |
>>>> PMS is the spec, and it doesn't need fixing, since it |
| 16 |
>>>> accurately reflects the situation we're dealing with. |
| 17 |
>>>> |
| 18 |
>>> |
| 19 |
>>> Sorry, I misread PMS as PMs (portage, paludis, etc). |
| 20 |
>>> |
| 21 |
>>> And, for support to be official for ebuilds or eclasses to |
| 22 |
>>> query IUSE (or other globals) within phase functions, then the |
| 23 |
>>> 'spec' (PMS) is probably all that needs to be 'fixed'. Right? |
| 24 |
>>> |
| 25 |
>>> So, in EAPI=6, we propose something that'll make it official |
| 26 |
>>> (ie a querying function; or ensure that PMs can provide these |
| 27 |
>>> variables along with their proper 'effective' values, or their |
| 28 |
>>> in-ebuild 'explicit' values, or whatever it is we want to say |
| 29 |
>>> can be relied upon, to the environment). |
| 30 |
>>> |
| 31 |
>> |
| 32 |
>> The problem of waiting for eapi6 to specify CURRENT behavior is |
| 33 |
>> that we don't know how much time will need to wait until it's |
| 34 |
>> approved (as I think eapi5 cannot include this "extra" function |
| 35 |
>> as was approved some hours ago). Other option would be to fast |
| 36 |
>> release some kind of eapi5.1 adding this... but, again, I think |
| 37 |
>> we are discussing about something that could be resolved as |
| 38 |
>> simply as specifying current behavior for all existing eapis (as |
| 39 |
>> we are in fact doing in the tree) and rely on new eapis for |
| 40 |
>> future hypothetical changes on it. |
| 41 |
> |
| 42 |
> The key question is: How would you formally describe the current |
| 43 |
> behavior? |
| 44 |
> |
| 45 |
> I think someone already noted it's not reliable behavior in all |
| 46 |
> places. |
| 47 |
> |
| 48 |
|
| 49 |
I think we'd need an audit of what current behaviour is and then |
| 50 |
define based on that. Possibly removing cases where the 'expected' |
| 51 |
behaviour isn't occurring (ie, bugs that just aren't being caught). |
| 52 |
|
| 53 |
I'm biased, so to me just auditing what portage does would be good |
| 54 |
enough. :D But probably the other PMs should be audited to before |
| 55 |
'official' behaviour should be described for PMS. |
| 56 |
|
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 59 |
|
| 60 |
iF4EAREIAAYFAlBbXzcACgkQ2ugaI38ACPBqywEAuXtOrfOy6R+JrwIxfAfcueDe |
| 61 |
ItsysItZBl+dKdsyShEA/iY8Oye4hyTJc01jT2deBmVPGm3P6Iu/0YZ/tismPAHv |
| 62 |
=2nvp |
| 63 |
-----END PGP SIGNATURE----- |
Archives