1 |
On Wednesday 17 May 2006 21:49, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 21:22:28 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> |
4 |
> wrote: |
5 |
> | On Wednesday 17 May 2006 20:44, Ciaran McCreesh wrote: |
6 |
> | > Portage still relies upon being able to source ebuilds, even if |
7 |
> | > their EAPI isn't supported. |
8 |
> | |
9 |
> | Currently, nothing except the ability to parse bash directly would |
10 |
> | make it otherwise. Against my advise, there are no restrictions upon |
11 |
> | the EAPI variable. As such EAPI can not reliably be determined |
12 |
> | without understanding (or being) bash. |
13 |
> |
14 |
> Not exactly true. There's nothing to stop a package manager from |
15 |
> gracefully handling not even being able to source the ebuild. The way |
16 |
> Paludis handles this is to create fake version metadata for weird |
17 |
> ebuilds with EAPI set to "UNKNOWN". It's not perfect, but it avoids any |
18 |
> overly crazy behaviour. |
19 |
|
20 |
This is not the standard, nor what portage does. It is what portage should |
21 |
do, but not what it does. It would have been far preferable if doing an |
22 |
egrep on "^EAPI" would just be enough, but this is not true. EAPI can be |
23 |
defined even by EAPI="${PV}" (I know it is silly, but allowed). |
24 |
|
25 |
My concern is not what paludis does, but what portage does. This means |
26 |
that technically paludis can not support all EAPI cases properly (except |
27 |
bailing out when parsing fails). |
28 |
|
29 |
Paul |
30 |
|
31 |
-- |
32 |
Paul de Vrieze |
33 |
Gentoo Developer |
34 |
Mail: pauldv@g.o |
35 |
Homepage: http://www.devrieze.net |