1 |
On Wed, May 17, 2006 at 04:26:28PM +0100, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> wrote: |
4 |
> | Let me clarify my statement. I don't care about candy spinners. |
5 |
> | Paludis (or any other package manager that is to be integrated into |
6 |
> | gentoo) should basically be able to allow a level of mix and match. |
7 |
> | This means that at the initial import, it can be run on any package |
8 |
> | instead of portage, and the results still be usable for portage |
9 |
> | (possibly after a conversion stage). |
10 |
> | |
11 |
> | This allows testing out the package manager. |
12 |
> |
13 |
> Not realistic. It means that any new package manager can't do anything |
14 |
> new. I'd also like to point out that you can't upgrade to a new Portage |
15 |
> version, install some things, downgrade to an older Portage version and |
16 |
> expect things to carry on working. |
17 |
|
18 |
Actually, you can for .54 and 2.1. The only issue is cache backend |
19 |
changeover, but that's minor (--metadata, or let portage regen on it's |
20 |
own). |
21 |
|
22 |
Paludis has to work with the ebuilds that are in the tree now- if it |
23 |
becomes official, go nuts, redefine the standards as you like, until |
24 |
then it needs to remain ebuild level compatible with portage. |
25 |
|
26 |
Yes it castrates some of the shineys, but portage suffers the same for |
27 |
any non-versioned change. |
28 |
|
29 |
|
30 |
> | > | - No part of the tree, except those that by nature are paludis |
31 |
> | > | specific, may require the usage of paludis instead of portage. |
32 |
> | > | This requirement can only be removed after a decision is made by |
33 |
> | > | the council to retire portage in favour of paludis. |
34 |
> | > |
35 |
> | > Again, insane. EAPI allows ebuilds using things that developers have |
36 |
> | > been after for years (you know, slot and use deps) to be in the |
37 |
> | > tree in such a way that they appear masked to Portage. That's a |
38 |
> | > large part of the point of EAPI. |
39 |
> | |
40 |
> | Let's make clear why I put this in. Basically I am of the opinion |
41 |
> | that until a decision is made to make (in this case) paludis the |
42 |
> | primary package manager, all official packages should work with |
43 |
> | portage. Package masked packages are not considered official. |
44 |
> |
45 |
> What of EAPI masked packages? |
46 |
> |
47 |
> The same situation will occur when newer Portage versions supporting |
48 |
> newer EAPIs are released into p.mask or ~arch. Some packages will end |
49 |
> up relying upon something that isn't the stable package manager. |
50 |
|
51 |
One concern here- EAPI was added to version the ebuild format- as |
52 |
such, *everyone involved* should be defining the new EAPI. Defining |
53 |
one in one project, and having it end up in the tree is a no go. |
54 |
|
55 |
Well aware I used EAPI="prefix" for the prefix branch, but that also |
56 |
was for testing. It has not, nor will it ever touch the tree till |
57 |
when it's agreed upon by folks also. |
58 |
|
59 |
~harring |