Gentoo Archives: gentoo-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Paludis and Profiles
Date: Wed, 17 May 2006 16:02:02
Message-Id: 200605171748.33259.pauldv@gentoo.org
In Reply to: Re: [gentoo-dev] Paludis and Profiles by Ciaran McCreesh
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

Replies

Subject Author
Re: [gentoo-dev] Paludis and Profiles Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>