1 |
On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos wrote: |
2 |
> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió: |
3 |
> > Revised to use a separate variable for the name of the flag instead of |
4 |
> > reading IUSE, as suggested by Ciaran McCreesh. As a result of this |
5 |
> > change, vala.eclass now defaults to assuming that vala support is |
6 |
> > optional (which is the case in an overwhelming majority of ebuilds that |
7 |
> > would want to use this eclass). |
8 |
> |
9 |
> Sorry but, why even in_iuse function from eutils.eclass cannot be used? |
10 |
> If that is really not allowed, why we have that function in |
11 |
> eutils.eclass? |
12 |
> |
13 |
> There are lots of cases in eclasses relying on things like original |
14 |
> suggested way or in_iuse from eutils.eclass and would like to clarify |
15 |
> things before going with a more complex way than original. |
16 |
> |
17 |
> I already know Ciaran's opinion on this, but would like to know more |
18 |
> opinion and, most important, is this is really allowed or not and, if |
19 |
> not, we should try to migrate current eclasses to the "fixed" way if |
20 |
> there is really a way providing similar function. |
21 |
|
22 |
A fair number of existing eclasses and ebuilds rely on being able to |
23 |
read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently |
24 |
works with current versions of portage and bash (otherwise users would |
25 |
be complaining). But technically, these ebuilds/eclasses are relying on |
26 |
unspecified behavior. There is no immediate pressure to change them - |
27 |
after all, they work fine at the moment, and in the case of ebuilds, |
28 |
avoiding IUSE would probably require changes to the ebuild's API. |
29 |
|
30 |
But given that we are already making a change to vala_src_prepare's |
31 |
default behavior, it makes sense to ensure that the change in a way that |
32 |
respects the pms. Although it will almost certainly provide no practical |
33 |
benefits, it is still good style. |