El jue, 20-09-2012 a las 09:13 -0400, Ian Stakenvicius escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 20/09/12 03:41 AM, Michał Górny wrote: > > On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos <pa...@gentoo.org> > > wrote: > > > >> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev > >> escribió: > >>> Revised to use a separate variable for the name of the flag > >>> instead of reading IUSE, as suggested by Ciaran McCreesh. As a > >>> result of this change, vala.eclass now defaults to assuming > >>> that vala support is optional (which is the case in an > >>> overwhelming majority of ebuilds that would want to use this > >>> eclass). > >> > >> Sorry but, why even in_iuse function from eutils.eclass cannot > >> be used? If that is really not allowed, why we have that function > >> in eutils.eclass? > >> > >> There are lots of cases in eclasses relying on things like > >> original suggested way or in_iuse from eutils.eclass and would > >> like to clarify things before going with a more complex way than > >> original. > >> > >> I already know Ciaran's opinion on this, but would like to know > >> more opinion and, most important, is this is really allowed or > >> not and, if not, we should try to migrate current eclasses to the > >> "fixed" way if there is really a way providing similar function. > > > > Well, it works and people use it, so it's better to keep a good > > function rather than rely on people remembering to handle all > > stripping and splitting correctly. > > > > I wanted to propose fixing PMS but, as you can see, there are > > mysterious broken systems which nobody has ever seen but surely > > exist somewhere and Ciaran won't waste his time telling us where in > > his imagination it is, and thus we can't simply fix it. > > > > PMS may not need to be fixed, just the spec -- ie, (if I'm > understanding Ciaran properly), as long as the spec says that the > effective IUSE (or other globals) is available for access (via > function getter or however) during phase functions, then PMS will have > to guarantee it to be there. Right now they don't, and so even if it > works we can't rely on it working because said functionality might > break in the course of regular portage/other PMS development (and > doesn't need to be fixed because to date it's not in the spec). >
That isn't necessary what could occur if the behavior changes unexpectedly: as current behavior is already being assumed in eclasses/ebuilds, portage couldn't change it without, before, porting ebuilds/eclasses to use that new hypothetical behavior.
signature.asc
Description: This is a digitally signed message part
