1 |
On Wednesday 17 May 2006 15:57, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> |
4 |
> wrote: |
5 |
> | - Paludis must be able to handle a standard portage /var/db/pkg tree. |
6 |
> | This means that paludis can read it, and write it. Enabling mixing |
7 |
> | portage and paludis up to some degree. |
8 |
> |
9 |
> Paludis can read a Portage-generated VDB. Portage can't read a |
10 |
> Paludis-generated VDB, because Paludis has more features. |
11 |
> |
12 |
> | - Paludis must work with all current ebuilds, |
13 |
> |
14 |
> Portage does not work with all current ebuilds. |
15 |
> |
16 |
> | and support all features of portage. |
17 |
> |
18 |
> That's insane. Why should we support Portage-style 'candy' spinners? |
19 |
|
20 |
Let me clarify my statement. I don't care about candy spinners. Paludis |
21 |
(or any other package manager that is to be integrated into gentoo) |
22 |
should basically be able to allow a level of mix and match. This means |
23 |
that at the initial import, it can be run on any package instead of |
24 |
portage, and the results still be usable for portage (possibly after a |
25 |
conversion stage). |
26 |
|
27 |
This allows testing out the package manager. |
28 |
|
29 |
> | This includes recognition of EAPI |
30 |
> |
31 |
> Funnily enough, unlike Portage, Paludis has full EAPI handling. |
32 |
|
33 |
Great. And I agree that EAPI was not taken as far as it should within |
34 |
portage. |
35 |
|
36 |
> | and no renaming of the variables used. |
37 |
> |
38 |
> Why should Paludis emulate Portage internals that no-one uses? |
39 |
|
40 |
If they are internals I don't care. If they are part of the API exposed to |
41 |
ebuilds then these variables should still be provided. If variables are |
42 |
not part of the public API, but still used regularly I consider them |
43 |
still part of the API. |
44 |
|
45 |
> | - No part of the tree, except those that by nature are paludis |
46 |
> | specific, may require the usage of paludis instead of portage. This |
47 |
> | requirement can only be removed after a decision is made by the |
48 |
> | council to retire portage in favour of paludis. |
49 |
> |
50 |
> Again, insane. EAPI allows ebuilds using things that developers have |
51 |
> been after for years (you know, slot and use deps) to be in the tree in |
52 |
> such a way that they appear masked to Portage. That's a large part of |
53 |
> the point of EAPI. |
54 |
|
55 |
Let's make clear why I put this in. Basically I am of the opinion that |
56 |
until a decision is made to make (in this case) paludis the primary |
57 |
package manager, all official packages should work with portage. Package |
58 |
masked packages are not considered official. |
59 |
|
60 |
If this restriction is not applied, it would create the situation that a |
61 |
decision is forced upon the council by (paludis) having features |
62 |
available that the official primary package manager has not. Thus |
63 |
requiring the use of a secondary package manager for certain |
64 |
applications. This in fact makes that package manager primary. |
65 |
|
66 |
> | - It would be greatly beneficial if paludis would create and use |
67 |
> | .tbz2 packages, but this is not essential. |
68 |
> |
69 |
> Paludis will use its own binary format. |
70 |
|
71 |
I assume there are valid reasons. I agree that the binary support can be |
72 |
improved. |
73 |
|
74 |
Paul |
75 |
|
76 |
-- |
77 |
Paul de Vrieze |
78 |
Gentoo Developer |
79 |
Mail: pauldv@g.o |
80 |
Homepage: http://www.devrieze.net |