On Wed, Jun 25, 2003 at 12:36:00AM +0200, Tony Clark wrote:
[... Portage with DB backend ...]
> Not that I am aware of.  If there is let me know.

Yes, well, no... not really that I know of. Hmm, let me explain :)

We (a small research group) are currently investigating bringing Gentoo Linux
desktops to companies. One of the things we're investigating is having
Portage on a remote MySQL database _but_ still having a local Portage for
when the network goes down. This is indeed rather easy (it needs some patches
to portage.py so that it queries the server and not parses it's own cache or
ebuild collection) but our current implementation is faulty (well, it works
great, but it isn't flexible).

The next choice would be to have Portage enhanced with databasefunctionality
(using Python's DB-API) and support for remote databases. This way a local
Gentoo desktop (as most of the people have) would store it's information in
normal ebuilds (default behaviour), a local Berkeley DB (optional) or a
remote SQL-server (optional). This would mean that Portage be enhanced with a
medium-independent layer, and several sublayers (one for each medium) which
takes care of the medium-dependent stuff.

Alain was working on a similar layer-implementation, but has dropped it in
favor of another project. 

Also, as you might now, this would be a major rewrite, so it's not the
current priority :) So if you want to fasten the search-functionality, write
a script that parses /usr/portage/*/*/*.ebuild and puts it in a database,
create a small script that does a SQL-statement against the database, and use
that script instead of "emerge -[sS]".

Wkr,
	Sven Vermeulen

-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...