1 |
On Fri, 2004-12-03 at 10:01 +0100, Paul de Vrieze wrote: |
2 |
> At the point where there are proper modules in portage, I'm all for it to |
3 |
> make everything a module. |
4 |
It's coming down the pipe. Obviously done when it's done, but |
5 |
refactoring the tree code and moving it out of portage.py and into their |
6 |
own modules is my next target after I put the finishing touchs on cache |
7 |
refactoring, and contents backend refactoring (bit more then a finishing |
8 |
touch on the latter- need to do integration of it). |
9 |
|
10 |
> What I mean is that slack code should be |
11 |
> modularized in such a way that there is no trace of it when you don't |
12 |
> want it. |
13 |
For using a slack repository, it's possible/viable. For |
14 |
identifcation/merging of a slack tgz, that's a different case. Unless |
15 |
portage is dynamically loading all modules in a directory (or in a |
16 |
specified list), identification of the tgz will be tricky- _even_ if all |
17 |
slack related code is loaded on demand, that still leaves the nasty mess |
18 |
of writing hooks for modules to register functions for identification of |
19 |
a format. I honestly don't see that happening for a long while, I'd |
20 |
expect identification of the various formats to be handled in portage. |
21 |
|
22 |
> For the current system that means some wrapper of some kind. |
23 |
Define wrapper. module wrapper, seperate binary wrapper... |
24 |
|
25 |
> For |
26 |
> a modularized system that means that there is a slack package that |
27 |
> installs a number of slackware specific modules and configures portage to |
28 |
> use them. |
29 |
There really isn't/won't be any simple way to configure portage to be |
30 |
aware of new formats on the fly (imo). It's doable, but I disagree that |
31 |
no additional formats should be supported until the code is implemented |
32 |
that way- as is, we already have code in portage for handling our own |
33 |
binpkg format, and for rpms. |
34 |
~brian |
35 |
|
36 |
|
37 |
-- |
38 |
gentoo-portage-dev@g.o mailing list |