1 |
On Saturday 06 December 2003 20:35, Daniel Robbins wrote: |
2 |
> On Sat, 2003-12-06 at 07:26, Paul de Vrieze wrote: |
3 |
> > We need indeed a highlevel abstraction, and dep trackers are one of the |
4 |
> > modules. I think that access to the package tree is another, where |
5 |
> > caching can be modular too. |
6 |
> |
7 |
> If by "caching" you mean the metadata cache, this is something I want to |
8 |
> eliminate in portage-ng. I would like things to be designed to be fast |
9 |
> from the start, with no slow bash<->python linkage like there is in the |
10 |
> current portage that makes us require a metadata cache for decent |
11 |
> performance. |
12 |
|
13 |
What I mean with caching here is a module that maskerades as a tree |
14 |
representation, but actually is a cache that gets it's data from another |
15 |
"real" tree representation (be that installed, available ebuilds, or |
16 |
binaries). This cache module would in someway speed up the retrieval of the |
17 |
data from the cache. Possibly by a binary database or whatever means (I don't |
18 |
care). The thing I care about is that it should be optional, and there should |
19 |
be a caching module that minimizes memory use. |
20 |
|
21 |
> It should be possible to get portage-ng without caching running as fast |
22 |
> as portage does now when it has a fully up-to-date cache. Then if we |
23 |
> need more performance, portage-ng's datastore can be moved to a |
24 |
> database, or we can add an enhanced caching mode to make it even faster. |
25 |
> |
26 |
That would be cool. |
27 |
|
28 |
> For backwards compatibility with existing ebuilds, yes we will probably |
29 |
> still need the metadata cache since we'll still have some kind of bash |
30 |
> linkage. It's important to point out that the design of portage-ng will |
31 |
> not be tied to ebuilds. Ebuilds will likely become "legacy" build |
32 |
> scripts that are superceded by something a lot better, cleaner, powerful |
33 |
> and also faster for portage-ng. |
34 |
|
35 |
While I see the value of keeping ebuilds I agree that ebuilds have serious |
36 |
upward compatibility problems, so we might get a new format. (Also parseable |
37 |
without bash, and a way to add more complex dependency formats without |
38 |
breaking old scripts). |
39 |
|
40 |
Paul |
41 |
|
42 |
-- |
43 |
Paul de Vrieze |
44 |
Gentoo Developer |
45 |
Mail: pauldv@g.o |
46 |
Homepage: http://www.devrieze.net |