1 |
On Wednesday 17 May 2006 17:26, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> |
4 |
> wrote: |
5 |
> | Let me clarify my statement. I don't care about candy spinners. |
6 |
> | Paludis (or any other package manager that is to be integrated into |
7 |
> | gentoo) should basically be able to allow a level of mix and match. |
8 |
> | This means that at the initial import, it can be run on any package |
9 |
> | instead of portage, and the results still be usable for portage |
10 |
> | (possibly after a conversion stage). |
11 |
> | |
12 |
> | This allows testing out the package manager. |
13 |
> |
14 |
> Not realistic. It means that any new package manager can't do anything |
15 |
> new. I'd also like to point out that you can't upgrade to a new Portage |
16 |
> version, install some things, downgrade to an older Portage version and |
17 |
> expect things to carry on working. |
18 |
|
19 |
No, a package manager can have many features. However, until it is seen as |
20 |
a candidate for becomming the primary package manager (or when it can |
21 |
function fully as secondary package manager (not being the boss in the |
22 |
installation tree)), the official tree may not rely on those features. |
23 |
Otherwise we get to a situation where the official tree relies on an |
24 |
unofficial package manager. |
25 |
|
26 |
The difference between portage and paludis is that portage is the |
27 |
officially supported package manager. This support is limited to the |
28 |
newest versions, but it is still official. Until the decision is made to |
29 |
make paludis the official package manager it isn't. An unofficial package |
30 |
manager should not limit the usage of the official package manager. |
31 |
|
32 |
> | If they are internals I don't care. If they are part of the API |
33 |
> | exposed to ebuilds then these variables should still be provided. If |
34 |
> | variables are not part of the public API, but still used regularly I |
35 |
> | consider them still part of the API. |
36 |
> |
37 |
> This, funnily enough, is what we're doing. We're supporting things that |
38 |
> are actually used, and things that people might reasonably use. |
39 |
|
40 |
That is fair enough. |
41 |
|
42 |
> | Let's make clear why I put this in. Basically I am of the opinion |
43 |
> | that until a decision is made to make (in this case) paludis the |
44 |
> | primary package manager, all official packages should work with |
45 |
> | portage. Package masked packages are not considered official. |
46 |
> |
47 |
> What of EAPI masked packages? |
48 |
|
49 |
Nah. If a package requires the use of a non-primary package manager, that |
50 |
package effectively forces the use of that package manager. If that |
51 |
non-primary package manager can not coexist with the official package |
52 |
manager, the package effectively blocks the usage of the primary package |
53 |
manager. By blocking the usage of the official package manager, the |
54 |
package becomes unofficial and has no place in the official tree. |
55 |
|
56 |
This is basically to protect the official package manager. This is not |
57 |
because I like portage that much, but to provide some kind of unified |
58 |
direction. I am afraid that allowing various competing package managers |
59 |
would cause a wildfire of incompatible elements in the tree. Therefore |
60 |
there must be one official package manager that the tree works with. |
61 |
|
62 |
> The same situation will occur when newer Portage versions supporting |
63 |
> newer EAPIs are released into p.mask or ~arch. Some packages will end |
64 |
> up relying upon something that isn't the stable package manager. |
65 |
|
66 |
Portage is however the official package manager. This means that these |
67 |
packages do not hamper the position of the official package manager. |
68 |
|
69 |
Paul |
70 |
|
71 |
-- |
72 |
Paul de Vrieze |
73 |
Gentoo Developer |
74 |
Mail: pauldv@g.o |
75 |
Homepage: http://www.devrieze.net |