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