[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
From:       Pacho Ramos <pacho () gentoo ! org>
Date:       2012-09-21 19:01:46
Message-ID: 1348254106.2085.3.camel () belkin4
[Download RAW message or body]


El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 20/09/12 02:12 PM, Michael Mol wrote:
> > On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos <pacho@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 
> >>>> <axs@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.
> > 
> 
> I think we'd need an audit of what current behaviour is and then
> define based on that.  Possibly removing cases where the 'expected'
> behaviour isn't occurring (ie, bugs that just aren't being caught).
> 
> I'm biased, so to me just auditing what portage does would be good
> enough. :D  But probably the other PMs should be audited to before
> 'official' behaviour should be described for PMS.
> 

Will ask to portage people then to know what is current behavior

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]