| 1 |
On Thu, 18 May 2006 16:37:00 +0200 |
| 2 |
Paul de Vrieze <pauldv@g.o> wrote: |
| 3 |
|
| 4 |
> Cascading profiles form a tree with N nodes. Some of these nodes are |
| 5 |
> abstract in the sense that they are not directly usable. Say that |
| 6 |
> leaves M possible profiles. To have paludis be on par with portage, |
| 7 |
> each of these M profiles would have a leaf added for paludis. The |
| 8 |
> same holds for pkgcore and for any other package manager. This would |
| 9 |
> mean that we have N+2M profiles. With a paludis and pkgcore toplevel |
| 10 |
> profile this would even be worse and amount to approximately 3N |
| 11 |
> profiles. |
| 12 |
> |
| 13 |
> In the leaf version, all M paludis specific profiles are equal. |
| 14 |
|
| 15 |
OK, a valid technical objection. The way to avoid this, as I see it, is |
| 16 |
to remove all direct references to Portage and its dependencies |
| 17 |
(Python?) from the system set, and replace them with the virtual. Then |
| 18 |
make sure that no package assumes that Python will be in system, and |
| 19 |
explicitly depends on it where necessary. At that point, a system could |
| 20 |
sanely be installed with any package manager by installing it before |
| 21 |
the rest of the system set. |
| 22 |
|
| 23 |
Long term this is possibly a better solution, but in the short term it |
| 24 |
requires an order of magnitude more effort, and has a significant |
| 25 |
effect on every profile in the tree. My original intention was to avoid |
| 26 |
having to change anything for other developers or people who still want |
| 27 |
to use Portage. |
| 28 |
-- |
| 29 |
gentoo-dev@g.o mailing list |
Archives