1 |
Tiziano Müller wrote: |
2 |
> Joe Peterson wrote: |
3 |
> |
4 |
>> Ciaran McCreesh wrote: |
5 |
>>> And a file extension is far less obscurely complex than enforcing |
6 |
>>> arbitrary syntax restrictions upon ebuilds. |
7 |
>> I disagree. One is exposed to devs only as ebuild syntax; the other is |
8 |
>> exposed in an inappropriate location to everyone looking at the portage |
9 |
>> tree. |
10 |
>> |
11 |
>>> No it can't. EAPI has to be known before the source can start. Bash |
12 |
>>> doesn't provide traps for executing code upon changed variables. |
13 |
>> Doing it out-of-band solve this. |
14 |
>> |
15 |
>>> No, it's only needed once per non-trivial change. So we might as well |
16 |
>>> just change it for every EAPI. |
17 |
>> Huh? If the "new" portage knows how to determine the EAPI definitively |
18 |
>> (and that would be defined), it can deal with the differences. |
19 |
>> |
20 |
>>> And then how do we deal with EAPI 3, where the syntax changes again? |
21 |
>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes |
22 |
>> from there. If you change the way you declare EAPI each time, yeah, |
23 |
>> that's a problem, but I'm not sure why that would ne necessary. |
24 |
> No, that is not the problem. |
25 |
> |
26 |
> Example: |
27 |
> In EAPI 42 we define that the package manager must provide a global function |
28 |
> extract_depend_from_setup_py() such that it is callable at a global level |
29 |
> in an ebuild like this |
30 |
> |
31 |
> *snip start* |
32 |
> |
33 |
> # Copyright 1999-2007 Gentoo Foundation |
34 |
> # Distributed under the terms of the GNU General Public License v2 |
35 |
> # $Header: $ |
36 |
> |
37 |
> EAPI=42 |
38 |
> |
39 |
> DESCRIPTION="A library aiming to support agile and test-driven python |
40 |
> development on various levels." |
41 |
> SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz" |
42 |
> HOMEPAGE="http://codespeak.net/py/" |
43 |
> KEYWORDS="~amd64 ~x86" |
44 |
> SLOT="0" |
45 |
> LICENSE="MIT" |
46 |
> IUSE="" |
47 |
> |
48 |
> extract_depend_from_setup_py |
49 |
> |
50 |
> *snip end* |
51 |
> |
52 |
> Now, a package manager (or a tool) not knowing EAPI 42 will fail when it |
53 |
> tries to source the above ebuild to determine the EAPI version (as it is |
54 |
> being currently done as far as I understood it) because |
55 |
> extract_depend_from_setup_py is undefined. |
56 |
> So it won't even be able to read out the EAPI. |
57 |
> |
58 |
> With the EAPI in the filename tools now knowing EAPI-42 will either ignore |
59 |
> the above foo-1.0.ebuild-42 or mask it because they may identify the |
60 |
> EAPI-version without sourcing the ebuild. |
61 |
> |
62 |
|
63 |
Check if exists a line EAPI=*$, if does and the rest of the string |
64 |
matches an understood eapi, go on sourcing, otherwise ignore/mask it... |
65 |
|
66 |
lu |
67 |
|
68 |
-- |
69 |
|
70 |
Luca Barbato |
71 |
Gentoo Council Member |
72 |
Gentoo/linux Gentoo/PPC |
73 |
http://dev.gentoo.org/~lu_zero |
74 |
|
75 |
-- |
76 |
gentoo-dev@l.g.o mailing list |