| 1 |
On Thu, 20 Sep 2012 08:43:11 +0200 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió: |
| 5 |
> > Revised to use a separate variable for the name of the flag instead |
| 6 |
> > of reading IUSE, as suggested by Ciaran McCreesh. As a result of |
| 7 |
> > this change, vala.eclass now defaults to assuming that vala support |
| 8 |
> > is optional (which is the case in an overwhelming majority of |
| 9 |
> > ebuilds that would want to use this eclass). |
| 10 |
> |
| 11 |
> Sorry but, why even in_iuse function from eutils.eclass cannot be |
| 12 |
> used? If that is really not allowed, why we have that function in |
| 13 |
> eutils.eclass? |
| 14 |
> |
| 15 |
> There are lots of cases in eclasses relying on things like original |
| 16 |
> suggested way or in_iuse from eutils.eclass and would like to clarify |
| 17 |
> things before going with a more complex way than original. |
| 18 |
> |
| 19 |
> I already know Ciaran's opinion on this, but would like to know more |
| 20 |
> opinion and, most important, is this is really allowed or not and, if |
| 21 |
> not, we should try to migrate current eclasses to the "fixed" way if |
| 22 |
> there is really a way providing similar function. |
| 23 |
|
| 24 |
Well, it works and people use it, so it's better to keep a good |
| 25 |
function rather than rely on people remembering to handle all stripping |
| 26 |
and splitting correctly. |
| 27 |
|
| 28 |
I wanted to propose fixing PMS but, as you can see, there are |
| 29 |
mysterious broken systems which nobody has ever seen but surely exist |
| 30 |
somewhere and Ciaran won't waste his time telling us where in his |
| 31 |
imagination it is, and thus we can't simply fix it. |
| 32 |
|
| 33 |
-- |
| 34 |
Best regards, |
| 35 |
Michał Górny |
Archives