Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michael Mol]

On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <pacho@g.o> 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
>> > <axs@g.o> 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