| 1 |
On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze <pauldv@g.o> |
| 2 |
wrote: |
| 3 |
| Let me clarify my statement. I don't care about candy spinners. |
| 4 |
| Paludis (or any other package manager that is to be integrated into |
| 5 |
| gentoo) should basically be able to allow a level of mix and match. |
| 6 |
| This means that at the initial import, it can be run on any package |
| 7 |
| instead of portage, and the results still be usable for portage |
| 8 |
| (possibly after a conversion stage). |
| 9 |
| |
| 10 |
| This allows testing out the package manager. |
| 11 |
|
| 12 |
Not realistic. It means that any new package manager can't do anything |
| 13 |
new. I'd also like to point out that you can't upgrade to a new Portage |
| 14 |
version, install some things, downgrade to an older Portage version and |
| 15 |
expect things to carry on working. |
| 16 |
|
| 17 |
| > | and no renaming of the variables used. |
| 18 |
| > |
| 19 |
| > Why should Paludis emulate Portage internals that no-one uses? |
| 20 |
| |
| 21 |
| If they are internals I don't care. If they are part of the API |
| 22 |
| exposed to ebuilds then these variables should still be provided. If |
| 23 |
| variables are not part of the public API, but still used regularly I |
| 24 |
| consider them still part of the API. |
| 25 |
|
| 26 |
This, funnily enough, is what we're doing. We're supporting things that |
| 27 |
are actually used, and things that people might reasonably use. |
| 28 |
|
| 29 |
| > | - No part of the tree, except those that by nature are paludis |
| 30 |
| > | specific, may require the usage of paludis instead of portage. |
| 31 |
| > | This requirement can only be removed after a decision is made by |
| 32 |
| > | the council to retire portage in favour of paludis. |
| 33 |
| > |
| 34 |
| > Again, insane. EAPI allows ebuilds using things that developers have |
| 35 |
| > been after for years (you know, slot and use deps) to be in the |
| 36 |
| > tree in such a way that they appear masked to Portage. That's a |
| 37 |
| > large part of the point of EAPI. |
| 38 |
| |
| 39 |
| Let's make clear why I put this in. Basically I am of the opinion |
| 40 |
| that until a decision is made to make (in this case) paludis the |
| 41 |
| primary package manager, all official packages should work with |
| 42 |
| portage. Package masked packages are not considered official. |
| 43 |
|
| 44 |
What of EAPI masked packages? |
| 45 |
|
| 46 |
The same situation will occur when newer Portage versions supporting |
| 47 |
newer EAPIs are released into p.mask or ~arch. Some packages will end |
| 48 |
up relying upon something that isn't the stable package manager. |
| 49 |
|
| 50 |
-- |
| 51 |
Ciaran McCreesh |
| 52 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
| 53 |
|
| 54 |
|
| 55 |
-- |
| 56 |
gentoo-dev@g.o mailing list |
Archives