1 |
On Thursday 02 December 2004 17:11, Brian Harring wrote: |
2 |
> Back to the 'make it a wrapper' thing, for it to be external, that's |
3 |
> not in line with the current goals of most of the portage developers- |
4 |
> see genone's omecron design spec, and jstubbs compilation of portage |
5 |
> goals. |
6 |
> Additionally, it will be a pain in the ass forcing the wrapper to |
7 |
> basically duplicate dependency resolution, eg, pulling from it's |
8 |
> tree/repository when possible, falling back to querying portage. |
9 |
> |
10 |
> If it's going to be implemented, it should be implemented _in_ portage |
11 |
> as a specific tree type, with the format properly wrapped/abstracted. |
12 |
> Portage currently isn't incredibly far along in internally wrapping the |
13 |
> ebuild format into it's own class, but it is intended. |
14 |
> ~brian |
15 |
|
16 |
At the point where there are proper modules in portage, I'm all for it to |
17 |
make everything a module. What I mean is that slack code should be |
18 |
modularized in such a way that there is no trace of it when you don't |
19 |
want it. For the current system that means some wrapper of some kind. For |
20 |
a modularized system that means that there is a slack package that |
21 |
installs a number of slackware specific modules and configures portage to |
22 |
use them. |
23 |
|
24 |
Paul |
25 |
|
26 |
-- |
27 |
Paul de Vrieze |
28 |
Gentoo Developer |
29 |
Mail: pauldv@g.o |
30 |
Homepage: http://www.devrieze.net |