On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos 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.
A fair number of existing eclasses and ebuilds rely on being able to read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently works with current versions of portage and bash (otherwise users would be complaining). But technically, these ebuilds/eclasses are relying on unspecified behavior. There is no immediate pressure to change them - after all, they work fine at the moment, and in the case of ebuilds, avoiding IUSE would probably require changes to the ebuild's API. But given that we are already making a change to vala_src_prepare's default behavior, it makes sense to ensure that the change in a way that respects the pms. Although it will almost certainly provide no practical benefits, it is still good style.
