| 1 |
El jue, 20-09-2012 a las 03:33 -0400, Alexandre Rostovtsev escribió: |
| 2 |
> On Thu, 2012-09-20 at 08:43 +0200, Pacho Ramos wrote: |
| 3 |
> > El jue, 20-09-2012 a las 02:14 -0400, Alexandre Rostovtsev escribió: |
| 4 |
> > > Revised to use a separate variable for the name of the flag instead of |
| 5 |
> > > reading IUSE, as suggested by Ciaran McCreesh. As a result of this |
| 6 |
> > > change, vala.eclass now defaults to assuming that vala support is |
| 7 |
> > > optional (which is the case in an overwhelming majority of ebuilds that |
| 8 |
> > > would want to use this eclass). |
| 9 |
> > |
| 10 |
> > Sorry but, why even in_iuse function from eutils.eclass cannot be used? |
| 11 |
> > If that is really not allowed, why we have that function in |
| 12 |
> > eutils.eclass? |
| 13 |
> > |
| 14 |
> > There are lots of cases in eclasses relying on things like original |
| 15 |
> > suggested way or in_iuse from eutils.eclass and would like to clarify |
| 16 |
> > things before going with a more complex way than original. |
| 17 |
> > |
| 18 |
> > I already know Ciaran's opinion on this, but would like to know more |
| 19 |
> > opinion and, most important, is this is really allowed or not and, if |
| 20 |
> > not, we should try to migrate current eclasses to the "fixed" way if |
| 21 |
> > there is really a way providing similar function. |
| 22 |
> |
| 23 |
> A fair number of existing eclasses and ebuilds rely on being able to |
| 24 |
> read IUSE, whether directly or via in_iuse/use_if_iuse, so it evidently |
| 25 |
> works with current versions of portage and bash (otherwise users would |
| 26 |
> be complaining). But technically, these ebuilds/eclasses are relying on |
| 27 |
> unspecified behavior. There is no immediate pressure to change them - |
| 28 |
> after all, they work fine at the moment, and in the case of ebuilds, |
| 29 |
> avoiding IUSE would probably require changes to the ebuild's API. |
| 30 |
> |
| 31 |
|
| 32 |
The problem is that I suspect that, maybe, this behavior was present and |
| 33 |
supported even in eapi0 (when, if I don't misremember, portage behavior |
| 34 |
was taken with small modifications as start point for newer eapis) then, |
| 35 |
maybe, this is simply a problem of forgetting to document this behavior |
| 36 |
that looks to work and be supported for all EAPIs for ages, making the |
| 37 |
need of waiting for eapi6 to use this useless and a nonsense. |
| 38 |
|
| 39 |
|
| 40 |
> But given that we are already making a change to vala_src_prepare's |
| 41 |
> default behavior, it makes sense to ensure that the change in a way that |
| 42 |
> respects the pms. Although it will almost certainly provide no practical |
| 43 |
> benefits, it is still good style. |
| 44 |
> |
| 45 |
|
| 46 |
The problem is that there is no gain as it moves from autodetecting USE |
| 47 |
to need to manually review ebuild and add another variable to specify it |
| 48 |
manually :|, it clearly has cons over using "automatic" way to fix an |
| 49 |
unspecified behavior that could be fixed simply "specifying" it as that |
| 50 |
behavior is there for ages, is used in the tree for a long time and we |
| 51 |
are already relying on it for many eclasses/ebuilds. The other option |
| 52 |
would be to move all of them to another way alternative way to, once |
| 53 |
eapi6 is approved, revert them to previous situation, causing us to lose |
| 54 |
a lot of time with no gain. |
Archives