1 |
On Wed, May 17, 2006 at 02:57:05PM +0100, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> wrote: |
4 |
> | - Paludis must be able to handle a standard portage /var/db/pkg tree. |
5 |
> | This means that paludis can read it, and write it. Enabling mixing |
6 |
> | portage and paludis up to some degree. |
7 |
> |
8 |
> Paludis can read a Portage-generated VDB. Portage can't read a |
9 |
> Paludis-generated VDB, because Paludis has more features. |
10 |
|
11 |
What features? You're tracking CONFIG_PROTECT_*, and saving a copy of |
12 |
the eclass (icky solution, but we've discussed that in the past). |
13 |
|
14 |
Beyond that? |
15 |
|
16 |
|
17 |
> | - Paludis must work with all current ebuilds, |
18 |
> |
19 |
> Portage does not work with all current ebuilds. |
20 |
|
21 |
Name a few please, ones that are portage incompatibility rather then |
22 |
"ebuild no longer works against other ebuilds in the tree". Can't do |
23 |
anything about the latter, but the former without proof is fud. |
24 |
|
25 |
|
26 |
> | and support all features of portage. |
27 |
> |
28 |
> That's insane. Why should we support Portage-style 'candy' spinners? |
29 |
|
30 |
I'd expect he's talking more about stuff like having an ebuild |
31 |
binary/script for walking the phases of an ebuild for development. |
32 |
|
33 |
|
34 |
> | This includes recognition of EAPI |
35 |
> |
36 |
> Funnily enough, unlike Portage, Paludis has full EAPI handling. |
37 |
|
38 |
Please clarify on the "full"- since portage relies on EAPI protection |
39 |
already, any issues you see with it's implementation I'd love to know. |
40 |
|
41 |
|
42 |
> | and no renaming of the variables used. |
43 |
> |
44 |
> Why should Paludis emulate Portage internals that no-one uses? |
45 |
|
46 |
Moot issue, as I pointed out, dev-lang/perl (and others) are affected |
47 |
by it (so someone uses it). |
48 |
|
49 |
Additionally, you went and commited the vars into paludis (doing |
50 |
exactly what I said to do), thank you- lets avoid the 5 emails back |
51 |
and forth in the future however please... |
52 |
|
53 |
~harring |