On Saturday 06 December 2003 20:35, Daniel Robbins wrote:
> On Sat, 2003-12-06 at 07:26, Paul de Vrieze wrote:
> > We need indeed a highlevel abstraction, and dep trackers are one of the
> > modules. I think that access to the package tree is another, where
> > caching can be modular too.
>
> If by "caching" you mean the metadata cache, this is something I want to
> eliminate in portage-ng. I would like things to be designed to be fast
> from the start, with no slow bash<->python linkage like there is in the
> current portage that makes us require a metadata cache for decent
> performance.

What I mean with caching here is a module that maskerades as a tree 
representation, but actually is a cache that gets it's data from another 
"real" tree representation (be that installed, available ebuilds, or 
binaries). This cache module would in someway speed up the retrieval of the 
data from the cache. Possibly by a binary database or whatever means (I don't 
care). The thing I care about is that it should be optional, and there should 
be a caching module that minimizes memory use.

> It should be possible to get portage-ng without caching running as fast
> as portage does now when it has a fully up-to-date cache. Then if we
> need more performance, portage-ng's datastore can be moved to a
> database, or we can add an enhanced caching mode to make it even faster.
>
That would be cool.

> For backwards compatibility with existing ebuilds, yes we will probably
> still need the metadata cache since we'll still have some kind of bash
> linkage. It's important to point out that the design of portage-ng will
> not be tied to ebuilds. Ebuilds will likely become "legacy" build
> scripts that are superceded by something a lot better, cleaner, powerful
> and also faster for portage-ng.

While I see the value of keeping ebuilds I agree that ebuilds have serious 
upward compatibility problems, so we might get a new format. (Also parseable 
without bash, and a way to add more complex dependency formats without 
breaking old scripts).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net