Gentoo Archives: gentoo-dev

From: Alexandre Rostovtsev <tetromino@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala
Date: Thu, 20 Sep 2012 07:34:39
Message-Id: 1348126415.14335.63.camel@rook
In Reply to: Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala by Pacho Ramos
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.

Replies