El vie, 21-09-2012 a las 21:01 +0200, Pacho Ramos escribió: > 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 <pa...@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 > > >>>> <a...@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
Here it's: http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg02830.html
signature.asc
Description: This is a digitally signed message part
