One interesting application I can think of using a database backend is
for making a "portage server" serving portage ebuilds and recording the
cache information (as in what is installed with what USE flags) for
every single client machine having an "account" on the db. So in effect
you would have all your machines without any portage-related files apart
from the "emergedb" command and accessory tools. It could be usefull for
anyone who needs to deploy a lot of differently configured Gentoo
machines really fast. It could also be usefull for administration of
production Gentoo machines freeing them of have any "portage bloat"
(bloat not in the bad sense, I love portage  (here you would have the
machines connect to your central portage server. Very interesting even
though it is of limited use to many people.

On Fri, 2003-02-07 at 18:34, Yannick Koehler wrote:
> For the fun of it, I created a little tool very custom and untested that will 
> read the the cache files of gentoo and generate on the stdout a valid xml 
> file.
> 
> Now the schema/dtd has been created without any thinking.  This may or not 
> open the door to people to experiment with a gentoo equivalent database.

...

> Discussion with carspaski reveal thought that the use of the database will 
> actually not speed up emerge.  Because emerge loads the cache inside an 
> internal memory database and python allow him to leave that in memory in 
> between runs making it very fast and efficient as only the require entry of 
> the database gets loaded instead of the whole database.
> 
> Some benefit I see from the xml db is for side-tools, for example search 
> description of ebuilds is faster when using xml db as it is a single file and 
> software only look for string that start with <description>.  One can use 
> grep/regexp to do such query or built an xml capable application.
-- 
Vano D <gentoo-dev <at> europeansoftware.com>

--
gentoo-dev <at> gentoo.org mailing list