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