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 15:18:58
Message-Id: 200605171711.10418.pauldv@gentoo.org
In Reply to: Re: [gentoo-dev] Paludis and Profiles by Ciaran McCreesh
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

Replies

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