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