| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 20/09/12 03:41 AM, Michał Górny wrote: |
| 5 |
> On Thu, 20 Sep 2012 08:43:11 +0200 Pacho Ramos <pacho@g.o> |
| 6 |
> wrote: |
| 7 |
> |
| 8 |
>> El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev |
| 9 |
>> escribió: |
| 10 |
>>> Revised to use a separate variable for the name of the flag |
| 11 |
>>> instead of reading IUSE, as suggested by Ciaran McCreesh. As a |
| 12 |
>>> result of this change, vala.eclass now defaults to assuming |
| 13 |
>>> that vala support is optional (which is the case in an |
| 14 |
>>> overwhelming majority of ebuilds that would want to use this |
| 15 |
>>> eclass). |
| 16 |
>> |
| 17 |
>> Sorry but, why even in_iuse function from eutils.eclass cannot |
| 18 |
>> be used? If that is really not allowed, why we have that function |
| 19 |
>> in eutils.eclass? |
| 20 |
>> |
| 21 |
>> There are lots of cases in eclasses relying on things like |
| 22 |
>> original suggested way or in_iuse from eutils.eclass and would |
| 23 |
>> like to clarify things before going with a more complex way than |
| 24 |
>> original. |
| 25 |
>> |
| 26 |
>> I already know Ciaran's opinion on this, but would like to know |
| 27 |
>> more opinion and, most important, is this is really allowed or |
| 28 |
>> not and, if not, we should try to migrate current eclasses to the |
| 29 |
>> "fixed" way if there is really a way providing similar function. |
| 30 |
> |
| 31 |
> Well, it works and people use it, so it's better to keep a good |
| 32 |
> function rather than rely on people remembering to handle all |
| 33 |
> stripping and splitting correctly. |
| 34 |
> |
| 35 |
> I wanted to propose fixing PMS but, as you can see, there are |
| 36 |
> mysterious broken systems which nobody has ever seen but surely |
| 37 |
> exist somewhere and Ciaran won't waste his time telling us where in |
| 38 |
> his imagination it is, and thus we can't simply fix it. |
| 39 |
> |
| 40 |
|
| 41 |
PMS may not need to be fixed, just the spec -- ie, (if I'm |
| 42 |
understanding Ciaran properly), as long as the spec says that the |
| 43 |
effective IUSE (or other globals) is available for access (via |
| 44 |
function getter or however) during phase functions, then PMS will have |
| 45 |
to guarantee it to be there. Right now they don't, and so even if it |
| 46 |
works we can't rely on it working because said functionality might |
| 47 |
break in the course of regular portage/other PMS development (and |
| 48 |
doesn't need to be fixed because to date it's not in the spec). |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
-----BEGIN PGP SIGNATURE----- |
| 53 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 54 |
|
| 55 |
iF4EAREIAAYFAlBbFoQACgkQ2ugaI38ACPCWIAEAkDBX6zRm9uAygFTAoNuVKPEq |
| 56 |
Weq2eFQATLdYjUQ1HhoA/0dG89SayOG3gjSefG92A62H+EeBARQpPpa/xxAqoESi |
| 57 |
=hhU4 |
| 58 |
-----END PGP SIGNATURE----- |
Archives